[RFC][PATCHES] xattr stuff and interactions with io_uring

[Al Viro <viro@zeniv.linux.org.uk>]

	The series below is a small-scale attempt at sanitizing the
interplay between io_uring and normal syscalls.  It is limited to
xattr-related syscalls and I would like to have a similar approach taken
a lot further than that.

	Right now we have an ad-hoc mess, with io_uring stuff hooked
at different layers to syscall guts.  And it keeps growing and getting
messier.

	As far as I can tell, the general rules are

* we want arguments copied in when request is submitted to io_uring.
Rationale: userland caller should be able to have that stuff on his
stack frame, rather than keeping it around until the request completion.
Fair enough.

* destination for the stuff we want copied _out_ (results of read(),
etc.)  has to stay around until the IO completion.  In other words, such
references remain as userland pointers until the request is executed.
Fair enough.

* the things get less clear-cut where we are talking about bulk data
copied _in_ - write() arguments, for example.  In some cases we do
handle that at request execution time, in some we do not (setsockopt
vs. setxattr vs. write, for example).  Decided on individual basis?

* some argument validation is done when request is submitted; however,
anything related to resolving pathnames (at least - there may be other
such areas) is done only at the time request is processed.  Rationale:
previous requests might alter the state in question and we want the
effects of such changes visible to our request.

* pathnames are copied in at submission time and resolved at execution
time; descriptors are resolved at submission time, except when used in
dirfd role.

	What I propose for xattr stuff (and what could serve as a model
for other cases) is two families of helpers; one takes struct file
reference + whatever other arguments we want, another - dfd + filename +
lookup_flags + other arguments; filename is passed as a struct filename
reference, which is consumed by the helper.

	Normal syscalls are easily expressed via those; io_uring side is
also apparently OK.  Not sure if it's flexible enough, though - e.g.
IORING_OP_MKDIRAT et.al. end up resolving the descriptor _twice_
and can't have it coming from io_uring analogue of descriptor table.
It might make more sense to allow a variant that would have dirfd already
resolved to file reference.  It's not that hard to do on fs/namei.c side
(set_nameidata() and path_init() would have to be taught about that,
and that's more of less it), but... we need to figure out whether it
makes better sense to have descriptor resolution prompt or delayed on
the io_uring side - i.e. at submission or at execution time.

	Anyway, for now I'm following the model we have for do_mkdirat()
et.al.  It's definitely flexible enough on the syscall side; in particular,
rebasing ...xattrat(2) patch on top of that had been trivial.  It also
promises some fairly nice simplifications wrt struct filename vs. audit,
but that's a separate story.

	Currently the branch lives in
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.xattr
Individual patches in followups.

1/9)	switch to CLASS(fd) use.  Obvious.

2/9)	rename struct xattr_ctx to kernel_xattr_ctx
prep from the ...xattrat() series, to reduce the PITA for rebase

3/9)	io_[gs]etxattr_prep(): just use getname()
getname_flags(_, LOOKUP_FOLLOW) is ridiculous.

4/9)	new helper: import_xattr_name()
exact same logics for copying the xattr name in, dealing with
overflows, etc. in a lot of places.  

5/9)	replace do_setxattr() with saner helpers
file_setxattr(file, ctx) and filename_setxattr(dfd, filename, lookup_flags, ctx).
Don't mess with do_setxattr() directly - use those.  In particular, don't
bother with the ESTALE loop in io_uring - it doesn't belong there.

6/9)	replace do_getxattr() with saner helpers
Same on getxattr() side.

7/9)	new helpers: file_listxattr(), filename_listxattr()
Same, except that io_uring doesn't use those, so the helpers are left static.

8/9)	new helpers: file_removexattr(), filename_removexattr()
Ditto

9/9)	fs/xattr: add *at family syscalls
Rebased patch introducing those, with a bunch of fixes folded in so we don't
create bisect hazard there.  Potentially interesting bit is the pathname-handling
logics - getname_xattr(pathname, flags) returns a struct filename reference
if no AT_EMPTY_PATH had been given or if the pathname was non-NULL and turned out
to be non-empty.  With (NULL,AT_EMPTY_PATH) or (empty string, AT_EMPTY_PATH) it
returns NULL (and it tries to skip the allocation using the same trick with
get_user() that vfs_empty_path() uses).  That helper simplifies a lot of things,
and it should be cheap enough to convert fsetxattr(2) et.al. to the unified
path_setxattrat() and its ilk.  IF we get a slowdown on those, we can always
expand and simplify the calls in fsetxattr(2) and friends.

Anyway, comments, review and testing would be very welcome.