Thread (60 messages) read the whole thread 60 messages, 8 authors, 2024-10-28

Re: [PATCH v1 02/14] futex: Extend the FUTEX2 flags

From: "Arnd Bergmann" <arnd@arndb.de>
Date: 2023-08-01 06:03:13
Also in: linux-arch, linux-mm, lkml

On Tue, Aug 1, 2023, at 00:43, Thomas Gleixner wrote:
On Mon, Jul 31 2023 at 23:33, Peter Zijlstra wrote:
quoted
On Mon, Jul 31, 2023 at 11:14:11PM +0200, Thomas Gleixner wrote:
quoted
--- 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help