On 2019/3/16 5:39, Andrea Arcangeli wrote: > On Fri, Mar 08, 2019 at 03:10:08PM +0800, zhong jiang wrote: >> I can reproduce the issue in arm64 qemu machine. The issue will leave after >> applying the >> patch. >> >> Tested-by: zhong jiang <zhongji...@huawei.com> > Thanks a lot for the quick testing! > >> Meanwhile, I just has a little doubt whether it is necessary to use RCU to >> free the task struct or not. >> I think that mm->owner alway be NULL after failing to create to process. >> Because we call mm_clear_owner. > I wish it was enough, but the problem is that the other CPU may be in > the middle of get_mem_cgroup_from_mm() while this runs, and it would > dereference mm->owner while it is been freed without the call_rcu > affter we clear mm->owner. What prevents this race is the As you had said, It would dereference mm->owner after we clear mm->owner.
But after we clear mm->owner, mm->owner should be NULL. Is it right? And mem_cgroup_from_task will check the parameter. you mean that it is possible after checking the parameter to clear the owner . and the NULL pointer will trigger. :-( Thanks, zhong jiang > rcu_read_lock() in get_mem_cgroup_from_mm() and the corresponding > call_rcu to free the task struct in the fork failure path (again only > if CONFIG_MEMCG=y is defined). Considering you can reproduce this tiny > race on arm64 qemu (perhaps tcg JIT timing variantions helps?), you > might also in theory be able to still reproduce the race condition if > you remove the call_rcu from delayed_free_task and you replace it with > free_task. > > . >
