On Tue, 12 Nov 2024 at 15:06, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> I am fine not optimizing out the legacy FS_ACCESS_PERM event
> and just making sure not to add new bad code, if that is what you prefer
> and I also am fine with using two FMODE_ flags if that is prefered.
So iirc we do have a handful of FMODE flags left. Not many, but I do
think a new one would be fine.
And if we were to run out (and I'm *not* suggesting we do that now!)
we actually have more free bits in "f_flags".
That f_flags set of flags is a mess for other reasons: we expose them
to user space, and we define the bits using octal numbers for random
bad historical reasons, and some architectures specify their own set
or bits, etc etc - nasty.
But if anybody is really worried about running out of f_mode bits, we
could almost certainly turn the existing
unsigned int f_flags;
into a bitfield, and make it be something like
unsigned int f_flags:26, f_special:6;
instead, with the rule being that "f_special" only gets set at open
time and never any other time (to avoid any data races with fcntl()
touching the other 24 bits in the word).
[ Bah. I thought we had 8 unused bits in f_flags, but I went and
looked. sparc uses 0x2000000 for __O_TMPFILE, so we actually only have
6 bits unused in f_flags. No actual good reason for the sparc choice I
think, but it is what it is ]
Anyway, I wouldn't begrudge you a bit if that cleans this fsnotify
mess up and makes it much simpler and clearer. I really think that if
we can do this cleanly, using a bit in f_mode is a good cause.
Linus
