Searched hist:"287 e68f4b5559df6f3a3e9e82996b1902fd2fe15" (Results 1 – 1 of 1) sorted by relevance
| /optee_os/core/arch/arm/mm/ |
| H A D | mobj_ffa.c | 287e68f4b5559df6f3a3e9e82996b1902fd2fe15 Wed Oct 11 08:47:26 UTC 2023 Jens Wiklander <jens.wiklander@linaro.org> core: ffa: fix race in mobj_put() and ffa_inactivate()
Prior to this patch there was a race condition when mobj_put()
is calling ffa_inactivate().
D/TC:0 0 ffa_inactivate:525 cookie 0x100000000000
D/TC:0 1 mobj_ffa_get_by_cookie:401 cookie 0x100000000000 active: refc 1
D/TC:? 1 read_console:114 got 0xd
D/TC:0 1 ffa_inactivate:525 cookie 0x100000000000
D/TC:0 0 ffa_inactivate:525 cookie 0x100000000000
E/TC:0 0 Panic at core/arch/arm/mm/mobj_ffa.c:527 <ffa_inactivate>
E/TC:0 0 TEE load address @ 0xe100000
E/TC:0 0 Call stack:
E/TC:0 0 0x0e108c0c print_kernel_stack at ??:?
E/TC:0 0 0x0e115b8c __do_panic at core/kernel/panic.c:24
E/TC:0 0 0x0e10a238 ffa_inactivate at mobj_ffa.c:?
E/TC:0 0 0x0e107318 __thread_std_smc_entry at ??:?
As now explained in ffa_inactivate():
/*
* pop_from_list() can fail to find the mobj if we had just
* decreased the refcount to 0 in mobj_put() and was going to
* acquire the shm_lock but another thread found this mobj and
* reinitialized the refcount to 1. Then before we got cpu time the
* other thread called mobj_put() and deactivated the mobj again.
* ...
*/
If our thread is delayed even further we may even inactivate an
unrelated mobj that happened to reuse the same piece of memory.
Fix this by adding another guarding condition so that the mobj is
guaranteed to be valid until ffa_inactivate() has returned. By adding a
new member in struct mobj_ffa, inactive_refs, we keep track of
references even when the mobj have been moved to the inactive list.
Adds a comment describing the non-trivial life cycle of struct mobj_ffa.
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
|