[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1413684978.17869.18.camel@linux-t7sj.site>
Date: Sat, 18 Oct 2014 19:16:18 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Matteo Franchin <Matteo.Franchin@....com>,
Darren Hart <dvhart@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Mike Galbraith <umgwanakikbuti@...il.com>
Subject: Re: [PATCH] futex: Ensure get_futex_key_refs() always implies a
barrier
On Sat, 2014-10-18 at 13:50 -0700, Linus Torvalds wrote:
> On Sat, Oct 18, 2014 at 12:58 PM, Davidlohr Bueso <dave@...olabs.net> wrote:
> >
> > And [get/put]_futex_keys() shouldn't even be called for private futexes.
> > The following patch had some very minor testing on a 60 core box last
> > night, but passes both Darren's and perf's tests. So I *think* this is
> > right, but lack of sleep and I overall just don't trust them futexes!
>
> Hmm. I don't see the advantage of making the code more complex in
> order to avoid the functions that are no-ops for the !fshared case?
>
> IOW, as far as I can tell, this patch doesn't actually really *change*
> anything. Am I missing something?
Right, all we do is avoid a NOP, but I don't see how this patch makes
the code more complex. In fact, the whole idea is to make it easier to
read and makes the key referencing differences between shared and
private futexes crystal clear, hoping to mitigate future bugs.
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists