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

[Aleksa Sarai]

On 2026-06-03, Jori Koolstra <jkoolstra@xxxxxxxxx> wrote:
> 
> > Op 03-06-2026 16:13 CEST schreef Aleksa Sarai <cyphar@xxxxxxxxxx>:
> > 
> >  
> > 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).
> > 
> 
> Okay, that makes sense. But you can reuse those bits in asm-generic if you just
> redefine the new O_ flag in the conflicting arch-specific fcntls, right? Maybe
> we don't want that, but that leaves fewer bits in the O_ space.

Actually the number of usable bits we have today is the same, regardless
of whether we choose to skip the "cursed" bits today or we keep filling
holes until we cannot express a bit on every architecture -- either way
you will eventually be unable to allocate a bit on every architecture
after the same number of steps.

But there is a usability difference -- if we use the same bits
everywhere for future O_* flags they are less painful to manually define
for userspace and less likely to lead to bugs (which was the same
argument used for uniform syscall numbers).

(Not to mention that we have the high-32-bit OPENAT2_* flag space now,
and I expect we will see very few new O_* flags because they are very
hard to add safely due to the -EINVAL problem we've discussed before.)

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

Attachment: signature.asc
Description: PGP signature