Re: [LTP] [PATCH v2 03/10] setxattr01: add setxattrat variant

[Cyril Hrubis <chrubis@suse.cz>]

Hi!
> > And as for filesystem support, it looks like TMPFS has
> > CONFIG_TMPFS_XATTR option so it could be enabled or disabled, however
> > they should be supported for native Linux filesystems such as ext, btrfs
> > or xfs.
> >
> > And we have to handle EOPNOTSUPP for setxattr() as well, so the test
> > setup would look like:
> >
> > 	if (tst_variant)
> > 		setxattrat_supported();
> > 	else
> > 		setxattr_supported();
> 
> The problem I have with this approach is that the whole kernel
> implementation of setxattr() is based on setxattrat() and this test is
> just moving through the same code.

The problem at hand is that the *attrat() syscalls were added to 6.13,
we are going to be stuck for a decade with kernels that does not support
these. Which means that we have to make sure to check for ENOSYS for
the at family of the xattr syscalls somewhere anyways and we have to
make sure that the coverage for the older syscalls is sufficient too.

> I would like to give a bare minimum attention. At the same time, we
> need to test a syscall by calling it with the right data, on files,
> that is something we are already doing during the test. For instance,
> we don't have a "foo" run and we are just going around setup() which
> is really slow only for filesystems testing.  In general, letting the
> syscall to fail inside test won't get much time.

Technically you can call the setxattrat() with a dummy parameters, they
does not even have to be correct, because if the syscall is not
supported in the kernel you will get ENOSYS as soon as the kernel
attempts to fetch the handler form the syscall table.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp