Re: linux-next: build failure after merge of the vfs-brauner tree

[Aleksa Sarai]

On 2026-06-03, Jori Koolstra <jkoolstra@xxxxxxxxx> wrote:
> 
> > Op 27-05-2026 15:09 CEST schreef Aleksa Sarai <aleksa@xxxxxxxxxxxx>:
> > 
> > If we could also get some comments in asm-generic that tell you which
> > flag bits are "cursed", that would also be quite great. My impression is
> > a fair number of people forget to check the arch-specific headers, so
> > having a note in the generic one would let us avoid this issue in future
> > (and IMHO will be more effective than just switching from octal).
> > 
> 
> Just to be sure, what do you mean by cursed here? Maybe just a reminder that
> there are arch-specific O_ flags? A list of all of them that may have an
> arch specific redefinition is basically all of them...

I was mainly thinking of the ones that appear free but actually aren't
-- so these are the ones where there are only arch-specific flags that
take them.

Basically, I would prefer the list in the asm-generic header be
something like:

 #define O_FOO 0x001
 #define O_BAR 0x002
 /* 0x004 must not be used -- it conflicts with flags on alpha and s390. */
 #define O_BAZ 0x010
 /* 0x020 must not be used -- it conflicts with flags on parisc. */

The fact that some flags have their order mixed up on different
architectures is funny trivia but when allocating a new flag, the thing
that trips most people up is that it looks like a flag is free in
asm-generic but some architecture is using that flag and you'll only
find out when someone compile-tests for that other architecture.

Depending on how many O_* flag bits we have, this might even allow us to
enforce non-arch-specific O_* flags (like we did for syscall numbers a
few years ago).

-- 
Aleksa Sarai
Founding Engineer at Amutable
https://www.cyphar.com/

Attachment: signature.asc
Description: PGP signature