[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <10cccd1f-76a1-13be-1173-670c3fcdf921@suse.cz>
Date: Mon, 11 Dec 2017 08:37:11 +0100
From: Jiri Slaby <jslaby@...e.cz>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ingo Molnar <mingo@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Darren Hart <dvhart@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/1] futex: futex_wake_op, fix sign_extend32 sign bits
On 12/10/2017, 09:50 PM, Linus Torvalds wrote:
> On Thu, Nov 30, 2017 at 6:35 AM, Jiri Slaby <jslaby@...e.cz> wrote:
>> sign_extend32 counts the sign bit parameter from 0, not from 1. So we
>> have to use "11" for 12th bit, not "12".
>
> This interface is crap. It really doesn't make much sense. I wonder
> how many people have gotten this wrong, but it's hard to tell.
I tend to agree, because it really surprised me. So at that time I
searched for most (all?) uses of the interface, checked them and all of
them *seem* to be fine.
> I'm applying this directly to my tree since I didn't see anybody else
> react to it, but the whole pattern worries me.
>
> Also, clearly nobody actually uses the odder corners of futex ops
> anyway. Maybe we should deprecate them entirely?
>
> Jiri, did you notice by testing, or what?
I noticed it by coincidence while fixing the strace build test failures
-- e78c38f6bdd9 (futex: futex_wake_op, do not fail on invalid op). I
compiled a bit modified futex_atomic_op_inuser in userspace to test the
conversion and the added check and it did not work.
And yes, somebody (tglx?) noted already that this interface is old and
perhaps unused.
thanks,
--
js
suse labs
Powered by blists - more mailing lists