Closed jenswi-linaro closed 9 months ago
There is no fallback if an earlier execution stage left a suspended tee thread open. Worst case effect would be regular sessions will not reach OP-TEE, in case sys_thread_cnt == total_thread_cnt - lost_thread_cnt. Should it be addressed?
The worst case is a total deadlock in the secure world if threads are left suspended, that's basically a DOS by starvation of CPU.
A warning in
optee_smc_do_call_with_arg()
?if (res.a0 == OPTEE_SMC_RETURN_ETHREAD_LIMIT) { + WARN_ONCE(!w->sys_thread, "TEE thread count mismatch\n") /* * Out of threads in secure world, wait for a thread * become available. */ optee_cq_wait_for_completion(&optee->call_queue, &w); } else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) {
Yes, it makes sense.
Adding the WARN_ONCE
I've posted the changes to LKML: system session patches v5.
Note I removed the call to WARN_ONCE()
I suggested. I found the backtrace information printed does not add much value.
Patch v6 posted, see https://lore.kernel.org/lkml/20230505173012.881083 series.
Closing. The feature is being addressed through the LKML: see latest post https://lore.kernel.org/lkml/20231030084812.905549-1-etienne.carriere@foss.st.com/.
An alternative to what is proposed in https://github.com/linaro-swg/linux/pull/109
@etienne-lms feel free to use these patches if they make sense to you.