lkml.org 
[lkml]   [2017]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-next: manual merge of the rcu tree with the tip tree
----- On Aug 1, 2017, at 10:15 AM, Andy Lutomirski luto@kernel.org wrote:

> On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>> /*
>> * The full memory barrier implied by mm_cpumask update operations
>> * is required by the membarrier system call.
>> */
>>
>> What we want to order here is:
>>
>> prev userspace memory accesses
>> schedule
>> <full mb> (it's already there) [A]
>> update to rq->curr changing the rq->curr->mm value
>> <full mb> (provided by mm_cpumask updates in switch_mm on x86) [B]
>
> If I understand this right, the issue with relying on CR3 writes is
> that the target CPU could switch to a kernel thread and back to the
> same user mm white the membarrier caller is reading its mm, right?

The current implementation of context_switch() does:

mm = next->mm;
oldmm = prev->active_mm;

if (!mm)
next->active_mm = oldmm;

if (!prev->mm) {
prev->active_mm = NULL;
rq->prev_mm = oldmm;
}

so basically the only way to have a non-null rq->prev_mm when we
reach finish_task_switch() is to have a non-null prev->active_mm
in context_switch (kernel thread).

finish_task_switch() has:

struct mm_struct *mm = rq->prev_mm;
[...]
if (mm)
mmdrop(mm);

which issues a full memory barrier through atomic_dec_and_test(). This
happens to take care of this kthread->uthread scenario. I think it would
be important to document though.

Thanks,

Mathieu


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

\
 
 \ /
  Last update: 2017-08-01 17:41    [W:0.036 / U:3.772 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site