From: Matthew Bobrowski <repnop@google.com>
To: Gabriel Krisman Bertazi <krisman@collabora.com>
Cc: jack@suse.com, amir73il@gmail.com, ltp@lists.linux.it,
khazhy@google.com, kernel@collabora.com,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH v3 2/9] syscalls: fanotify: Add macro to require specific events
Date: Tue, 2 Nov 2021 11:58:58 +0000 [thread overview]
Message-ID: <YYEoAr743j3IO3ol@google.com> (raw)
In-Reply-To: <20211029211732.386127-3-krisman@collabora.com>
On Fri, Oct 29, 2021 at 06:17:25PM -0300, Gabriel Krisman Bertazi wrote:
> Add a helper for tests to fail if an event is not available in the
> kernel. Since some events only work with REPORT_FID or a specific
> class, update the verifier to allow those to be specified.
>
> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Made a single comment, otherwise this looks OK to me.
Reviewed-by: Matthew Bobrowski <repnop@google.com>
> ---
> Changes since v1:
> - Use SAFE_FANOTIFY_INIT instead of open coding. (Amir)
> - Use FAN_CLASS_NOTIF for fanotify12 testcase. (Amir)
> ---
> testcases/kernel/syscalls/fanotify/fanotify.h | 17 ++++++++++++++---
> testcases/kernel/syscalls/fanotify/fanotify03.c | 4 ++--
> testcases/kernel/syscalls/fanotify/fanotify10.c | 3 ++-
> testcases/kernel/syscalls/fanotify/fanotify12.c | 3 ++-
> 4 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/testcases/kernel/syscalls/fanotify/fanotify.h b/testcases/kernel/syscalls/fanotify/fanotify.h
> index c67db3117e29..820073709571 100644
> --- a/testcases/kernel/syscalls/fanotify/fanotify.h
> +++ b/testcases/kernel/syscalls/fanotify/fanotify.h
> @@ -266,14 +266,16 @@ static inline void require_fanotify_access_permissions_supported_by_kernel(void)
> SAFE_CLOSE(fd);
> }
>
> -static inline int fanotify_events_supported_by_kernel(uint64_t mask)
> +static inline int fanotify_events_supported_by_kernel(uint64_t mask,
> + unsigned int init_flags,
> + unsigned int mark_flags)
> {
> int fd;
> int rval = 0;
>
> - fd = SAFE_FANOTIFY_INIT(FAN_CLASS_CONTENT, O_RDONLY);
> + fd = SAFE_FANOTIFY_INIT(init_flags, O_RDONLY);
>
> - if (fanotify_mark(fd, FAN_MARK_ADD, mask, AT_FDCWD, ".") < 0) {
> + if (fanotify_mark(fd, FAN_MARK_ADD | mark_flags, mask, AT_FDCWD, ".") < 0) {
> if (errno == EINVAL) {
> rval = -1;
> } else {
> @@ -378,4 +380,13 @@ static inline int fanotify_mark_supported_by_kernel(uint64_t flag)
> fanotify_mark_supported_by_kernel(mark_type)); \
> } while (0)
>
> +#define REQUIRE_FANOTIFY_EVENTS_SUPPORTED_ON_FS(init_flags, mark_type, mask, fname) do { \
> + if (mark_type) \
> + REQUIRE_MARK_TYPE_SUPPORTED_ON_KERNEL(mark_type); \
> + if (init_flags) \
> + REQUIRE_FANOTIFY_INIT_FLAGS_SUPPORTED_ON_FS(init_flags, fname); \
> + fanotify_init_flags_err_msg(#mask, __FILE__, __LINE__, tst_brk_, \
> + fanotify_events_supported_by_kernel(mask, init_flags, mark_type)); \
> +} while (0)
> +
> #endif /* __FANOTIFY_H__ */
> diff --git a/testcases/kernel/syscalls/fanotify/fanotify03.c b/testcases/kernel/syscalls/fanotify/fanotify03.c
> index 26d17e64d1f5..2081f0bd1b57 100644
> --- a/testcases/kernel/syscalls/fanotify/fanotify03.c
> +++ b/testcases/kernel/syscalls/fanotify/fanotify03.c
> @@ -323,8 +323,8 @@ static void setup(void)
> require_fanotify_access_permissions_supported_by_kernel();
>
> filesystem_mark_unsupported = fanotify_mark_supported_by_kernel(FAN_MARK_FILESYSTEM);
> - exec_events_unsupported = fanotify_events_supported_by_kernel(FAN_OPEN_EXEC_PERM);
> -
> + exec_events_unsupported = fanotify_events_supported_by_kernel(FAN_OPEN_EXEC_PERM,
> + FAN_CLASS_CONTENT, 0);
> sprintf(fname, MOUNT_PATH"/fname_%d", getpid());
> SAFE_FILE_PRINTF(fname, "1");
>
> diff --git a/testcases/kernel/syscalls/fanotify/fanotify10.c b/testcases/kernel/syscalls/fanotify/fanotify10.c
> index 92e4d3ff3054..0fa9d1f4f7e4 100644
> --- a/testcases/kernel/syscalls/fanotify/fanotify10.c
> +++ b/testcases/kernel/syscalls/fanotify/fanotify10.c
> @@ -509,7 +509,8 @@ cleanup:
>
> static void setup(void)
> {
> - exec_events_unsupported = fanotify_events_supported_by_kernel(FAN_OPEN_EXEC);
> + exec_events_unsupported = fanotify_events_supported_by_kernel(FAN_OPEN_EXEC,
> + FAN_CLASS_CONTENT, 0);
I'm wondering whether this is the best combination of mask and
init_flags to use in this particular case? Maybe not to confuse future
readers, using FAN_CLASS_NOTIF explicitly here would be better, WDYT?
It doesn't make a difference, but it's something that caught my eye
while parsing this patch.
> filesystem_mark_unsupported = fanotify_mark_supported_by_kernel(FAN_MARK_FILESYSTEM);
> fan_report_dfid_unsupported = fanotify_init_flags_supported_on_fs(FAN_REPORT_DFID_NAME,
> MOUNT_PATH);
> diff --git a/testcases/kernel/syscalls/fanotify/fanotify12.c b/testcases/kernel/syscalls/fanotify/fanotify12.c
> index 76f1aca77615..c77dbfd8c23d 100644
> --- a/testcases/kernel/syscalls/fanotify/fanotify12.c
> +++ b/testcases/kernel/syscalls/fanotify/fanotify12.c
> @@ -222,7 +222,8 @@ cleanup:
>
> static void do_setup(void)
> {
> - exec_events_unsupported = fanotify_events_supported_by_kernel(FAN_OPEN_EXEC);
> + exec_events_unsupported = fanotify_events_supported_by_kernel(FAN_OPEN_EXEC,
> + FAN_CLASS_NOTIF, 0);
>
> sprintf(fname, "fname_%d", getpid());
> SAFE_FILE_PRINTF(fname, "1");
> --
> 2.33.0
/M
next prev parent reply other threads:[~2021-11-02 11:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-29 21:17 [PATCH v3 0/9] Test the new fanotify FAN_FS_ERROR event Gabriel Krisman Bertazi
2021-10-29 21:17 ` [PATCH v3 1/9] syscalls: fanotify: Add macro to require specific mark types Gabriel Krisman Bertazi
2021-11-02 11:27 ` Matthew Bobrowski
2021-11-02 12:13 ` Amir Goldstein
2021-11-03 16:13 ` [LTP] " Petr Vorel
2021-10-29 21:17 ` [PATCH v3 2/9] syscalls: fanotify: Add macro to require specific events Gabriel Krisman Bertazi
2021-10-30 6:11 ` Amir Goldstein
2021-11-02 11:58 ` Matthew Bobrowski [this message]
2021-11-02 12:11 ` Amir Goldstein
2021-10-29 21:17 ` [PATCH v3 3/9] syscalls/fanotify21: Introduce FAN_FS_ERROR test Gabriel Krisman Bertazi
2021-10-30 6:15 ` Amir Goldstein
2021-11-05 8:59 ` [LTP] " Petr Vorel
2021-10-29 21:17 ` [PATCH v3 4/9] syscalls/fanotify21: Validate the generic error info Gabriel Krisman Bertazi
2021-10-29 21:17 ` [PATCH v3 5/9] syscalls/fanotify21: Validate incoming FID in FAN_FS_ERROR Gabriel Krisman Bertazi
2021-11-05 9:49 ` [LTP] " Petr Vorel
2021-10-29 21:17 ` [PATCH v3 6/9] syscalls/fanotify21: Support submission of debugfs commands Gabriel Krisman Bertazi
2021-10-29 21:17 ` [PATCH v3 7/9] syscalls/fanotify21: Create a corrupted file Gabriel Krisman Bertazi
2021-10-29 21:17 ` [PATCH v3 8/9] syscalls/fanotify21: Test file event with broken inode Gabriel Krisman Bertazi
2021-10-29 21:17 ` [PATCH v3 9/9] syscalls/fanotify21: Test capture of multiple errors Gabriel Krisman Bertazi
2021-10-30 6:21 ` [PATCH v3 0/9] Test the new fanotify FAN_FS_ERROR event Amir Goldstein
2021-11-05 10:10 ` [LTP] " Petr Vorel
2021-11-05 13:02 ` Amir Goldstein
2021-11-05 13:10 ` Petr Vorel
2021-11-15 21:26 ` Petr Vorel
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=YYEoAr743j3IO3ol@google.com \
--to=repnop@google.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.com \
--cc=kernel@collabora.com \
--cc=khazhy@google.com \
--cc=krisman@collabora.com \
--cc=linux-ext4@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).