Re: [RFC PATCH 2/3] Fix: sched/membarrier: READ_ONCE p->mm in membarrier_global_expedited

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

----- On Sep 3, 2019, at 12:23 PM, Linus Torvalds torvalds@linux-foundation.org wrote:

> On Tue, Sep 3, 2019 at 9:00 AM Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>>
>> Due to the lack of READ_ONCE() on p->mm, this code can in fact turn into
>> a NULL deref when we hit do_exit() around exit_mm(). The first p->mm
>> read is before and sees !NULL, the second is after and does observe
>> NULL, which triggers a null pointer dereference.
> 
> This is horribly ugly, and I don't think it is necessary.
> 
> The way to fix the problem you are addressing in patches 2-3 is to
> move the MEMBARRIER_STATE_GLOBAL_EXPEDITED flag from the mm struct to
> the task struct, and avoiding the whole issue with "mm may be released
> at any point" that way.
> 
> Now, your reaction will be "but lots of threads can share an 'mm', so
> we can't do that", but that doesn't seem to be true. Looking at the
> place that _sets_ this, you already handle the single-thread cases
> specially, and the multiple threads has to do a "synchronize_rcu()".
> You might as well either walk the current CPU's and set it in all
> threads where the thread->mm matches the mm. And then you make the
> scheduler set the bit on newly scheduled entities.
> 
> NOTE! When you walk all current cpu's in
> membarrier_register_global_expedited(), you only look at the
> 'task->mm' _value_, you don't dereference it. And that's ok, because
> 'task' itself is stable, it's just mm that can go away.
> 
> Wouldn't that solve the issue much more cleanly?

Indeed it would! I just sent a patch as RFC implementing your idea.

Thanks!

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com