Messages in this thread | | | Date | Tue, 1 Aug 2017 15:40:32 +0000 (UTC) | From | Mathieu Desnoyers <> | Subject | Re: 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
| |