On Fri, Mar 18, 2022 at 2:59 PM Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> On top of the main io_uring branch, this pull request is for ensuring
> that the filename component of statx is stable after submit. That
> requires a few VFS related changes.
Ugh, I've pulled this, but I hate how it does that
int getname_statx_lookup_flags(int);
thing with 'int' for both the incoming and outgoing flags.
And I don't say that just because the existing path lookup functions
actually use 'unsigned int', and the code strives to do things like
unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_DIRECTORY;
So 'int' is ugly, but the _really_ ugly part is how we should have a
separate type for the LOOKUP_xyz flags.
That part isn't new to this change, but this change really highlights
how lacking in type safety that thing is.
The vfs code has a huge pile of different types of 'flags'. Half of
them are various variations of mount flags, I feel, with the whole
MS_xyz -> MNT_xyz thing going on. This is more of that horrid pattern.
At least the mnt code tried to call the variables that keep MNT_xyz
flags 'mnt_flags'. I'm not sure how consistent the code is about it,
but there's _some_ attempt at it.
I do wonder if we should at least try to have a special integer type
for these things that could be checked with sparse (which nobody does)
or at least used as documentation in the function prototypes to show
"this returns a flag of type 'lookup_flag_t' rather than just
'unsigned int' (or worse yet, 'int').
Anyway, I've pulled it, I just wanted to make my reaction to it public
in the hope that some bored vfs person goes "yeah, we should do that"
and works on it.
Linus
