From: Andrea Cervesato via ltp <ltp@lists.linux.it>
To: "Wake Liu via ltp" <ltp@lists.linux.it>
Cc: Wake Liu <wakel@google.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] syscalls/file_attr01: Allow EOPNOTSUPP when attributes is NULL
Date: Fri, 20 Mar 2026 08:57:39 +0000 [thread overview]
Message-ID: <69bd0c05.050a0220.271ac6.1276@mx.google.com> (raw)
In-Reply-To: <20260320075733.936817-1-wakel@google.com>
Hi Wake,
> The syscalls file_getattr and file_setattr may return EOPNOTSUPP
> instead of EFAULT when the ufattr argument is NULL, specifically on
> filesystems that do not support extended attributes (e.g., tmpfs when
> CONFIG_TMPFS_XATTR is disabled).
Patch is technically correct but EOPNOTSUPP should not be tested int this way,
since we are not checking the underlying kernel configuration. For instance,
we might have xattr support, but getting EOPNOTSUPP and have a TPASS. This
would be a kernel bug hidden by the test structure.
In other circumstances (if xattr was our testing goal) we might have used
.needs_kconfig, but in this case we should use a different approach:
- we verify at runtime that our kernel supports xattr via tst_kconfig_check()
- if kernel doesn't support xattr, we expect EOPNOTSUPP. Otherwise, EFAULT
In this way we make sure that syscalls are raising the proper error according
to the kernel configuration.
WDYT?
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-03-20 8:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 7:57 [LTP] [PATCH] syscalls/file_attr01: Allow EOPNOTSUPP when attributes is NULL Wake Liu via ltp
2026-03-20 8:57 ` Andrea Cervesato via ltp [this message]
2026-03-23 7:26 ` Wake Liu via ltp
2026-03-23 7:48 ` [LTP] [PATCH v2] syscalls/file_attr01: Dynamically expect EOPNOTSUPP on tmpfs without xattr Wake Liu via ltp
2026-03-23 9:07 ` 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=69bd0c05.050a0220.271ac6.1276@mx.google.com \
--to=ltp@lists.linux.it \
--cc=andrea.cervesato@suse.com \
--cc=wakel@google.com \
/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