[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191107094943.GF4131@hirez.programming.kicks-ass.net>
Date: Thu, 7 Nov 2019 10:49:43 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Darren Hart <darren@...art.com>,
Yi Wang <wang.yi59@....com.cn>,
Yang Tao <yang.tao172@....com.cn>,
Oleg Nesterov <oleg@...hat.com>,
Florian Weimer <fweimer@...hat.com>,
Carlos O'Donell <carlos@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [patch 09/12] futex: Provide state handling for exec() as well
On Wed, Nov 06, 2019 at 10:55:43PM +0100, Thomas Gleixner wrote:
> +static void futex_cleanup_end(struct task_struct *tsk, int state)
> +{
> + /*
> + * Lockless store. The only side effect is that an observer might
> + * take another loop until it becomes visible.
> + */
> + tsk->futex_state = state;
As I mentioned yesterday, paranoia would've made me write this as
smp_store_release(), also to avoid it creaping back into the locked
region.
That is, the comment above deals with it being visible late, but it
could be visible early.
At the same time, if this is a release, what does it pair with. The
obvious place would be the load in handle_exit_race() but that didn't
want to make sense last night -- and I'm not sure it wants to make more
sense today.
Powered by blists - more mailing lists