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

[Andrea Cervesato]

Hi,

On Tue Oct 7, 2025 at 4:35 PM CEST, Cyril Hrubis wrote:
> Hi!
>> > Can we please, in a subsequent patch, convert this part to our standard
>> > approach where we check for the availability in the test setup and
>> > expect the syscalls to be present if kernel is new enough?
>> 
>> What do you think it's the best way? Some of these tests have multiple
>> syscalls related to *xattrat and in this test in particular we are
>> testing 2 syscalls.
>
> The same what we do for the rest of the syscalls, introduce a
> setxattrat_supported() helper into a shared header that would call
> tst_brk(TCONF, "") if kernel is older than the version the syscall was
> added to and we got ENOSYS.
>
> We actually have to handle a few cases here:
>
> For setxattrat:
>   - ENOSYS -> kernel too old
>   - EOPNOTSUPP -> filesystem does not support extended attributes
>                   (e.g. vfat)
>
> 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. 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.

>
> At the moment the ENOSYS branch would be covered by the fallback
> function since it calls tst_syscall() but once the function gets added
> to libc the check would no longer happen, so we need to eventually
> handle the ENOSYS in the foo_supported() function as well.
>
>> Maybe the best way would be to check for HAVE_FUNC_* declarations in
>> this case, but then fallback function would fail anyway.
>
> No this does not work, the only way how to find out if a syscall is
> supported is to call it and check the return value.




-- 
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com