Hi Jens, Sumit,
The following change has recently been merged: tee: optee: Fix supplicant wait loop
(https://github.com/torvalds/linux/commit/70b0d6b0a199c5a3ee6c72f5e61681ed6f…).
This fix addresses the issue where the supplicant may terminate before the client due to
the shutdown sequence or a crash. However, it introduces a potential new issue - now that
the client is killable, what happens if it terminates before the supplicant?
During cleanup, the client would remove/free the request, while the request would still
be available in the request idr for the supplicant. Although I have not been able to
reproduce it, this could theoretically result in a kernel page fault.
To address this, there are a few options:
(1) Use rcu and access request under a read lock in optee_supp_recv and optee_supp_send.
(2) Reuse supp->mutex, ensuring that most of these functions run within the lock,
even though it may not always be necessary.
Could you confirm whether this behavior was intentional? If not, I am happy to
prepare a patch. Additionally, please let me know whether you prefer solution
(1) or (2), or if you have any other suggestions.
Thank you for your time.
Regards,
Amir
