public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: Andrea Cervesato <andrea.cervesato@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 03/10] setxattr01: add setxattrat variant
Date: Tue, 7 Oct 2025 16:35:34 +0200	[thread overview]
Message-ID: <aOUlNrZj7O0yFDBP@yuki.lan> (raw)
In-Reply-To: <DDC49J0CRCSN.3K67TAS5U4VES@suse.com>

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();

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.

-- 
Cyril Hrubis
chrubis@suse.cz

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

  reply	other threads:[~2025-10-07 14:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-07  6:46 [LTP] [PATCH v2 00/10] setxattrat coverage Andrea Cervesato
2025-10-07  6:46 ` [LTP] [PATCH v2 01/10] lapi: add struct xattr_args fallback Andrea Cervesato
2025-10-07 11:50   ` Cyril Hrubis
2025-10-07  6:46 ` [LTP] [PATCH v2 02/10] lapi: add setxattrat() fallback definition Andrea Cervesato
2025-10-07 12:05   ` Cyril Hrubis
2025-10-07 15:16   ` Cyril Hrubis
2025-10-07  6:46 ` [LTP] [PATCH v2 03/10] setxattr01: add setxattrat variant Andrea Cervesato
2025-10-07 12:29   ` Cyril Hrubis
2025-10-07 13:16     ` Andrea Cervesato via ltp
2025-10-07 14:35       ` Cyril Hrubis [this message]
2025-10-08 10:40         ` Andrea Cervesato via ltp
2025-10-08 12:16           ` Cyril Hrubis
2025-10-07  6:46 ` [LTP] [PATCH v2 04/10] setxattr02: " Andrea Cervesato
2025-10-07 12:40   ` Cyril Hrubis
2025-10-07  6:46 ` [LTP] [PATCH v2 05/10] setxattr03: " Andrea Cervesato
2025-10-07 15:11   ` Cyril Hrubis
2025-10-07  6:46 ` [LTP] [PATCH v2 06/10] lapi: add getxattrat() fallback Andrea Cervesato
2025-10-07 15:21   ` Cyril Hrubis
2025-10-07  6:46 ` [LTP] [PATCH v2 07/10] lapi: add removexattrat() fallback Andrea Cervesato
2025-10-07 15:26   ` Cyril Hrubis
2025-10-07  6:47 ` [LTP] [PATCH v2 08/10] lapi: add safe *xattrat macros Andrea Cervesato
2025-10-08  9:36   ` Cyril Hrubis
2025-10-07  6:47 ` [LTP] [PATCH v2 09/10] Add setxattrat01 test Andrea Cervesato
2025-10-08  9:44   ` Cyril Hrubis
2025-10-13  7:54     ` Andrea Cervesato via ltp
2025-10-07  6:47 ` [LTP] [PATCH v2 10/10] Add setxattrat02 test Andrea Cervesato
2025-10-08 10:02   ` Cyril Hrubis
2025-10-10 11:05     ` Andrea Cervesato via ltp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aOUlNrZj7O0yFDBP@yuki.lan \
    --to=chrubis@suse.cz \
    --cc=andrea.cervesato@suse.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox