Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-592-ga9d4a09b4b-fm-defalarms-20230725.001-ga9d4a09b
Mime-Version: 1.0
Message-Id: <2d9c843f-e884-47d3-a825-6402db0a2cb8@app.fastmail.com>
In-Reply-To: <87y1ivln1v.ffs@tglx>
References: <20230721102237.268073801@infradead.org>
 <20230721105743.819362688@infradead.org> <87edkonjrk.ffs@tglx>
 <87mszcm0zw.ffs@tglx>
 <20230731192012.GA11704@hirez.programming.kicks-ass.net>
 <87a5vbn5r0.ffs@tglx>
 <20230731213341.GB51835@hirez.programming.kicks-ass.net>
 <87y1ivln1v.ffs@tglx>
Date:   Tue, 01 Aug 2023 08:02:21 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Thomas Gleixner" <tglx@linutronix.de>,
        "Peter Zijlstra" <peterz@infradead.org>
Cc:     "Jens Axboe" <axboe@kernel.dk>, linux-kernel@vger.kernel.org,
        "Ingo Molnar" <mingo@redhat.com>,
        "Darren Hart" <dvhart@infradead.org>, dave@stgolabs.net,
        andrealmeid@igalia.com,
        "Andrew Morton" <akpm@linux-foundation.org>, urezki@gmail.com,
        "Christoph Hellwig" <hch@infradead.org>,
        "Lorenzo Stoakes" <lstoakes@gmail.com>, linux-api@vger.kernel.org,
        linux-mm@kvack.org, Linux-Arch <linux-arch@vger.kernel.org>,
        malteskarupke@web.de
Subject: Re: [PATCH v1 02/14] futex: Extend the FUTEX2 flags
Content-Type: text/plain
Precedence: bulk

On Tue, Aug 1, 2023, at 00:43, Thomas Gleixner wrote:
> On Mon, Jul 31 2023 at 23:33, Peter Zijlstra wrote:
>> On Mon, Jul 31, 2023 at 11:14:11PM +0200, Thomas Gleixner wrote:
>>> --- a/include/uapi/linux/futex.h
>>> +++ b/include/uapi/linux/futex.h
>>> @@ -74,7 +74,12 @@
>>>  struct futex_waitv {
>>>  	__u64 val;
>>>  	__u64 uaddr;
>>> -	__u32 flags;
>>> +	union {
>>> +		__u32	flags;
>>> +		__u32	size	: 2,
>>> +				: 5,
>>> +			private	: 1;
>>> +	};
>>>  	__u32 __reserved;
>>>  };
>>
>> Durr, I'm not sure I remember if that does the right thing across
>> architectures -- might just work. But I'm fairly sure this isn't the
>> only case of a field in a flags thing in our APIs. Although obviously
>> I can't find another case in a hurry :/
>
> I know, but that doesn't make these things more readable and neither an
> argument against doing it for futex2 :)
...
>
> Still that explicit bitfield does neither need comments nor does it
> leave room for interpretation.

It may be clear to the compiler, but without comments or
looking up psABI documentation I certainly wouldn't know
immediately which bits of the flags word overlay the bitfields
for a given combination of __BIG_ENDIAN/__LITTLE_ENDIAN
and __BIG_ENDIAN_BITFIELD/__LITTLE_ENDIAN_BITFIELD or
architectures with unusual struct alignment requirements
(m68k or arm-oabi).

I'd prefer to completely avoid the bitfield here. Maybe having
exclusive flags for each width would be less confusing, at the
cost of needing two more flag bits and a slightly more complicated
sanity check, or we could take an extra byte out of the __reserved
field to store the length.

       Arnd