[LTP] [PATCH] fanotify23: Make evictable marks tests more reliable

[Amir Goldstein]

On Thu, Aug 10, 2023 at 4:10 PM Jan Kara <jack@suse.cz> wrote:
>
> It has been observed that when fanotify23 test is run in a loop, it
> eventually fails as:
>
> fanotify23.c:112: TPASS: FAN_MARK_ADD failed with EEXIST as expected when trying to downgrade to evictable mark
> fanotify23.c:75: TPASS: FAN_MARK_REMOVE failed with ENOENT as expected after empty mask
> fanotify23.c:156: TPASS: Got no events as expected
> fanotify23.c:81: TFAIL: FAN_MARK_REMOVE did not fail with ENOENT as expected after drop_caches: SUCCESS (0)
>
> This is because repeated evictions of caches done by the test reclaim
> all freeable slab objects in the system. So when the test calls drop
> caches, only the dentry and inode of the test file are there to reclaim.
> But for inode to be reclaimed, dentry (which holds inode reference) has
> to be freed first and for dentry to be freed it has to first cycle
> through the LRU which takes two slab reclaim calls.
>
> Call drop caches twice to make sure dentry has chance to pass through
> the LRU and be reclaimed.
>
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
>  testcases/kernel/syscalls/fanotify/fanotify23.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/testcases/kernel/syscalls/fanotify/fanotify23.c b/testcases/kernel/syscalls/fanotify/fanotify23.c
> index 89fd4f36a09b..2d50f70585b7 100644
> --- a/testcases/kernel/syscalls/fanotify/fanotify23.c
> +++ b/testcases/kernel/syscalls/fanotify/fanotify23.c
> @@ -160,10 +160,15 @@ static void test_fanotify(void)
>         }
>
>         /*
> -        * drop_caches should evict inode from cache and remove evictable mark
> +        * drop_caches should evict inode from cache and remove evictable mark.
> +        * We call drop_caches twice as once the dentries will just cycle
> +        * through the LRU without being reclaimed and if there are no other
> +        * objects to reclaim, the slab reclaim will just stop instead of
> +        * retrying.
>          */
>         fsync_file(TEST_FILE);
>         SAFE_FILE_PRINTF(DROP_CACHES_FILE, "3");
> +       SAFE_FILE_PRINTF(DROP_CACHES_FILE, "3");
>
>         verify_mark_removed(TEST_FILE, "after drop_caches");

If this improves the reliability of the test, I have no problem with
the solution,
but I am a bit uneasy with the fact that fanotiy10 and fanotify23 have two
different mitigations.

Anyway, I think that the explanation above is true for some fs but xfs
inode lifetime and shrinkers for example and more complex, so it does
not hold. Right?
Meaning that the explanation is true because fanotify10 has:

        /* Shrinkers on other fs do not work reliably enough to
guarantee mark eviction on drop_caches */
        .dev_fs_type = "ext2",

Maybe that should be spelled out?

Thanks,
Amir.