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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox