public inbox for ltp@lists.linux.it
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox