[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200804165118.GN2657@hirez.programming.kicks-ass.net>
Date: Tue, 4 Aug 2020 18:51:18 +0200
From: peterz@...radead.org
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
Will Deacon <will@...nel.org>, paulmck <paulmck@...nel.org>,
Nicholas Piggin <npiggin@...il.com>,
Andy Lutomirski <luto@...capital.net>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Alan Stern <stern@...land.harvard.edu>,
linux-mm <linux-mm@...ck.org>
Subject: Re: [RFC PATCH 1/2] sched: Fix exit_mm vs membarrier
On Tue, Aug 04, 2020 at 10:48:41AM -0400, Mathieu Desnoyers wrote:
> Here is the scenario I have in mind:
> Userspace variables:
>
> int x = 0, y = 0;
>
> CPU 0 CPU 1
> Thread A Thread B
> (in thread group A) (in thread group B)
>
> x = 1
> barrier()
> y = 1
> exit()
> exit_mm()
> current->mm = NULL;
> r1 = load y
> membarrier()
> skips CPU 0 (no IPI) because its current mm is NULL
> r2 = load x
> BUG_ON(r1 == 1 && r2 == 0)
>
Ah, yes of course.
We really should have a bunch of these scenarios in membarrier.c.
Now, the above cannot happen because we have an unconditional
atomic_dec_and_test() in do_exit() before exit_mm(), but I'm sure
relying on that is a wee bit dodgy.
Powered by blists - more mailing lists