From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Will Deacon <will@kernel.org>, paulmck <paulmck@kernel.org>,
Nicholas Piggin <npiggin@gmail.com>,
Andy Lutomirski <luto@amacapital.net>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Alan Stern <stern@rowland.harvard.edu>,
linux-mm <linux-mm@kvack.org>
Subject: Re: [RFC PATCH 1/3] sched: fix exit_mm vs membarrier (v3)
Date: Wed, 7 Oct 2020 10:57:52 -0400 (EDT) [thread overview]
Message-ID: <1929468067.11124.1602082672412.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20201007142947.GG2628@hirez.programming.kicks-ass.net>
----- On Oct 7, 2020, at 10:29 AM, Peter Zijlstra peterz@infradead.org wrote:
> On Thu, Sep 24, 2020 at 01:25:06PM -0400, Mathieu Desnoyers wrote:
>> diff --git a/kernel/exit.c b/kernel/exit.c
>> index 733e80f334e7..0767a2dbf245 100644
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -475,7 +475,19 @@ static void exit_mm(void)
>> BUG_ON(mm != current->active_mm);
>> /* more a memory barrier than a real lock */
>> task_lock(current);
>> + /*
>> + * When a thread stops operating on an address space, the loop
>> + * in membarrier_private_expedited() may not observe that
>> + * tsk->mm, and the loop in membarrier_global_expedited() may
>> + * not observe a MEMBARRIER_STATE_GLOBAL_EXPEDITED
>> + * rq->membarrier_state, so those would not issue an IPI.
>> + * Membarrier requires a memory barrier after accessing
>> + * user-space memory, before clearing tsk->mm or the
>> + * rq->membarrier_state.
>> + */
>> + smp_mb__after_spinlock();
>> current->mm = NULL;
>> + membarrier_update_current_mm(NULL);
>> mmap_read_unlock(mm);
>> enter_lazy_tlb(mm, current);
>> task_unlock(current);
>
> This site seems to be lacking in IRQ disabling. As proposed it will
> explode on RT.
Right, so irq off is needed for accessing this_rq()'s fields safely,
correct ?
I'll fold that fix in my patch for the next round, thanks!
Mathieu
>
> Something like so to match kthread_unuse_mm().
>
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -486,11 +486,13 @@ static void exit_mm(void)
> * rq->membarrier_state.
> */
> smp_mb__after_spinlock();
> + local_irq_disable()
> current->mm = NULL;
> membarrier_update_current_mm(NULL);
> - mmap_read_unlock(mm);
> enter_lazy_tlb(mm, current);
> + local_irq_enable();
> task_unlock(current);
> + mmap_read_unlock(mm);
> mm_update_next_owner(mm);
> mmput(mm);
> if (test_thread_flag(TIF_MEMDIE))
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2020-10-07 14:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 17:25 [RFC PATCH 0/3] Membarrier updates Mathieu Desnoyers
2020-09-24 17:25 ` [RFC PATCH 1/3] sched: fix exit_mm vs membarrier (v3) Mathieu Desnoyers
2020-10-07 14:29 ` Peter Zijlstra
2020-10-07 14:57 ` Mathieu Desnoyers [this message]
2020-10-07 15:09 ` Peter Zijlstra
2020-09-24 17:25 ` [RFC PATCH 2/3] sched: membarrier: cover kthread_use_mm (v3) Mathieu Desnoyers
2020-10-02 8:33 ` [sched] bdfcae1140: will-it-scale.per_thread_ops -37.0% regression kernel test robot
2020-10-07 14:50 ` Mathieu Desnoyers
2020-10-20 3:24 ` [LKP] " Xing Zhengjun
2020-10-20 13:14 ` Mathieu Desnoyers
2020-10-22 1:54 ` Xing Zhengjun
2020-10-22 13:19 ` Mathieu Desnoyers
2020-10-23 5:37 ` Xing Zhengjun
2020-10-23 12:34 ` Mathieu Desnoyers
2020-10-07 15:07 ` [RFC PATCH 2/3] sched: membarrier: cover kthread_use_mm (v3) Peter Zijlstra
2020-10-07 15:39 ` Mathieu Desnoyers
2020-10-07 16:08 ` Peter Zijlstra
2020-10-07 16:11 ` Mathieu Desnoyers
2020-09-24 17:25 ` [RFC PATCH 3/3] sched: membarrier: document memory ordering scenarios Mathieu Desnoyers
2020-09-29 17:16 ` [RFC PATCH 0/3] Membarrier updates Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1929468067.11124.1602082672412.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=npiggin@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.