All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Zizhi Wo <wozizhi@huawei.com>
Cc: yangerkun@huawei.com, jack@suse.cz, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] fanotify10: Calling drop_cache twice to ensure the inode is evicted
Date: Tue, 3 Sep 2024 16:08:07 +0200	[thread overview]
Message-ID: <20240903140807.GA762653@pevik> (raw)
In-Reply-To: <20240830130003.3245531-1-wozizhi@huawei.com>

Hi all,

> In this test case, some scenarios are designed to verify whether the
> FANOTIFY_EVICTABLE flag takes effect: by verifying that information cannot
> be obtained from the corresponding inode after drop_cache, as this flag
> does not ping the inode.

> However, drop_cache is only performed once here, which may result in the
> inode not being released in NUMA scenarios. Suppose the inode is located
> on NUMA0 and the dentry is located on NUMA1; the first drop_cache can only
> ensure that the inode is added to the LRU list, but does not guarantee that
> evict() can been called because dispose_list does not yet include this
> inode when traversing NUMA0, which causes the testcase execution fail.

I wonder if there can be some detection that inode is evicted.
Or, can it happen that even 2x drop is not enough?

> For the single-file scenario in this testcase, executing drop_cache twice
> is necessary to ensure the inode is evicted, thus allowing the testcase to
> pass.

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

@Amir, Jan, could you please have a look?

Kind regards,
Petr

> Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
> ---
>  testcases/kernel/syscalls/fanotify/fanotify10.c | 2 ++
>  1 file changed, 2 insertions(+)

> diff --git a/testcases/kernel/syscalls/fanotify/fanotify10.c b/testcases/kernel/syscalls/fanotify/fanotify10.c
> index c6d8ec922..42018de0d 100644
> --- a/testcases/kernel/syscalls/fanotify/fanotify10.c
> +++ b/testcases/kernel/syscalls/fanotify/fanotify10.c
> @@ -515,6 +515,8 @@ static void drop_caches(void)
>  	if (syncfs(fd_syncfs) < 0)
>  		tst_brk(TBROK | TERRNO, "Unexpected error when syncing filesystem");

> +	/* Need to drop twice to ensure the inode is evicted. */
> +	SAFE_FILE_PRINTF(DROP_CACHES_FILE, "3");
>  	SAFE_FILE_PRINTF(DROP_CACHES_FILE, "3");
>  }

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

  reply	other threads:[~2024-09-03 14:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-30 13:00 [LTP] [PATCH] fanotify10: Calling drop_cache twice to ensure the inode is evicted Zizhi Wo via ltp
2024-09-03 14:08 ` Petr Vorel [this message]
2024-09-04  7:34   ` Zizhi Wo via ltp
2024-09-04  8:57   ` Amir Goldstein
2024-09-04  9:07   ` Jan Kara
2024-09-04  9:47     ` 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=20240903140807.GA762653@pevik \
    --to=pvorel@suse.cz \
    --cc=jack@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=wozizhi@huawei.com \
    --cc=yangerkun@huawei.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.