All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Kiryl Shutsemau <kas@kernel.org>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	David Hildenbrand <david@redhat.com>, Jan Kara <jack@suse.cz>,
	ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] fanotify24: Verify expected count/offset info in pre content events
Date: Mon, 20 Oct 2025 22:22:31 +0200	[thread overview]
Message-ID: <20251020202231.GA416401@pevik> (raw)
In-Reply-To: <20251017161639.2088158-1-amir73il@gmail.com>

Hi Amir, all,

> To test fix commit 28bba2c2935e2 ("fsnotify: Pass correct offset to
> fsnotify_mmap_perm()"), diversify the offsets and count used for mmap()
> write() and read() and verify that the FAN_PRE_ACCESS events report the
> expected count/offset.

> For the FAN_PRE_ACCESS events generated by execve(), we cannot
> anticipate the exact ranges, so we set 0 count to skip this verification.

> Also add prints of path of the fd passed with the event (not verified
> against expected path).

> Make sure that we take the expected error value for an operation
> (e.g. read) from a matching event type (e.g. FAN_PRE_ACCESS).

Thanks for the update.  LGTM, but it'd be great if some of kernel developers
also had look into it. Few minor notes below.

Reviewed-by: Petr Vorel <pvorel@suse.cz>

I also restarted failing jobs in github actions:
https://github.com/linux-test-project/ltp/actions/runs/18599812482

Unfortunately due patchwork API limitation, the failing jobs aren't replaced
with successful ones, instead the fixes are appended:
https://patchwork.ozlabs.org/project/ltp/patch/20251017161639.2088158-1-amir73il@gmail.com/

> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>  .../kernel/syscalls/fanotify/fanotify24.c     | 167 +++++++++++-------
>  1 file changed, 107 insertions(+), 60 deletions(-)

> diff --git a/testcases/kernel/syscalls/fanotify/fanotify24.c b/testcases/kernel/syscalls/fanotify/fanotify24.c
> index 27f0663ce..8f2dee55b 100644
> --- a/testcases/kernel/syscalls/fanotify/fanotify24.c
> +++ b/testcases/kernel/syscalls/fanotify/fanotify24.c
> @@ -9,6 +9,8 @@
>  /*\
>   * - Test fanotify pre-content events
>   * - Test respond to permission/pre-content events with cutsom error code
> + * - Test count/offset info bug that was fixed by commit
> + *   28bba2c2935e2 "fsnotify: Pass correct offset to fsnotify_mmap_perm()"
>   */

>  #define _GNU_SOURCE
> @@ -44,6 +46,8 @@
>  #define FILE_EXEC_PATH MOUNT_PATH"/"TEST_APP

>  static char fname[BUF_SIZE];
> +static char symlnk[BUF_SIZE];
> +static char fdpath[BUF_SIZE];
>  static char buf[BUF_SIZE];
>  static volatile int fd_notify;
>  static size_t page_sz;
> @@ -55,6 +59,8 @@ static char event_buf[EVENT_BUF_LEN];
>  struct event {
>  	unsigned long long mask;
>  	unsigned int response;
> +	unsigned long pgcount;
> +	unsigned long pgoff;
>  };

>  static struct tcase {
> @@ -68,11 +74,11 @@ static struct tcase {
>  		INIT_FANOTIFY_MARK_TYPE(INODE),
>  		FAN_OPEN_PERM | FAN_PRE_ACCESS,
>  		{
> -			{FAN_OPEN_PERM, FAN_ALLOW},
> -			{FAN_PRE_ACCESS, FAN_ALLOW},
> -			{FAN_PRE_ACCESS, FAN_ALLOW},
> -			{FAN_PRE_ACCESS, FAN_DENY_ERRNO(EIO)},
> -			{FAN_OPEN_PERM, FAN_DENY_ERRNO(EBUSY)}
> +			{FAN_OPEN_PERM, FAN_ALLOW,0 ,0},
nit: space is usually before comma, not after. I'll fix it before merge.
I also prefer to use designated initializers when there are more struct members
and some of them are zero. But it's up to you, or I can change it later in a
separate patch.

> +			{FAN_PRE_ACCESS, FAN_ALLOW, 2, 100},
> +			{FAN_PRE_ACCESS, FAN_ALLOW,0 ,0},
> +			{FAN_PRE_ACCESS, FAN_DENY_ERRNO(EIO),0 ,0},
> +			{FAN_OPEN_PERM, FAN_DENY_ERRNO(EBUSY),0 ,0}

...
> @@ -190,17 +196,19 @@ static void generate_events(struct tcase *tc)
>  	 */
>  	fd = SAFE_OPEN(fname, O_RDWR | O_CREAT, 0700);

> -	exp_errno = expected_errno(event->response);
> -	event++;
> -
> +	exp_errno = 0;
> +	if (event->mask & FAN_PRE_ACCESS) {
> +		exp_errno = expected_errno(event->response);
> +		event++;
> +	}
>  	exp_ret = exp_errno ? -1 : 1;
> -	errno = 0;
>  	/*
>  	 * FAN_PRE_ACCESS events are reported on map() and write(), but should
>  	 * not be reported when faulting in the user page at offset page_sz*100
>  	 * that is used as an input buffer to the write() syscall.
>  	 */
> -	addr = SAFE_MMAP(NULL, page_sz, PROT_READ, MAP_PRIVATE, fd, page_sz*100);
> +	errno = 0;
> +	addr = SAFE_MMAP(NULL, page_sz*2, PROT_READ, MAP_PRIVATE, fd, page_sz*100);
>  	if (!addr || errno != exp_errno) {
nit (unrelated to this change): I wonder if "!addr" is really needed (addr !=
MAP_FAILED in safe_mmap() should be enough, right?

>  		tst_res(TFAIL, "mmap() got errno %d (expected %d)", errno, exp_errno);
>  		exit(3);
> @@ -208,12 +216,14 @@ static void generate_events(struct tcase *tc)
>  		tst_res(TINFO, "mmap() got errno %d as expected", errno);
>  	}
...

Kind regards,
Petr

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

  reply	other threads:[~2025-10-20 20:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-17 16:16 [LTP] [PATCH] fanotify24: Verify expected count/offset info in pre content events Amir Goldstein
2025-10-20 20:22 ` Petr Vorel [this message]
2025-10-21  9:49   ` Jan Kara
2025-10-21 10:19   ` Amir Goldstein
2025-10-21 10:59     ` 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=20251020202231.GA416401@pevik \
    --to=pvorel@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=david@redhat.com \
    --cc=jack@suse.cz \
    --cc=kas@kernel.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=ltp@lists.linux.it \
    --cc=ryan.roberts@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.