public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: NeilBrown <neilb@suse.de>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/1] nfs/nfs08.sh: Add test for NFS cache invalidation
Date: Tue, 25 Apr 2023 15:48:45 +0200	[thread overview]
Message-ID: <20230425134845.GA3014439@pevik> (raw)
In-Reply-To: <ZEfRrOpPwkLuBQw5@rei>

> Hi!
> > v4 [1] of not yet upstreamed patch accidentally broke cache invalidation
> > for directories by clearing NFS_INO_INVALID_DATA inappropriately.
> > Although it was fixed in v5 [2] thus kernel was not actually broken,
> > it's better to prevent this in the future.

> > [1] https://lore.kernel.org/linux-nfs/167649314509.15170.15885497881041431304@noble.neil.brown.name/
> > [2] https://lore.kernel.org/linux-nfs/167943762461.8008.3152357340238024342@noble.neil.brown.name/

...
> > --- /dev/null
> > +++ b/testcases/network/nfs/nfs_stress/nfs08.sh
> > @@ -0,0 +1,20 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0-or-later
> > +# Copyright (c) 2023 Petr Vorel <pvorel@suse.cz>
> > +# Test reproducer for broken NFS cache invalidation for directories.
> > +# Based on reproducer from Neil Brown <neilb@suse.de>
> > +
> > +TST_TESTFUNC="do_test"
> > +
> > +do_test()
> > +{
> > +	tst_res TINFO "testing NFS cache invalidation for directories"
> > +
> > +	touch 1
> > +	EXPECT_PASS 'ls | grep 1'
> > +
> > +	touch 2
> > +	EXPECT_PASS 'ls | grep 2'
> > +}

> I do not get how this actually detects case invalidation, it probably
> does, but slightly better description how this actually excercises the
> case would help.

The behavior is:

"touch 1" asks for data invalidation (new file created), therefore following ls
(EXPECT_PASS 'ls | grep 1') fills the cache.  "touch 2" should again ask for
data invalidation, but it the unfixed v4 version of the patch it did not
resulted to cache invalidation.  Therefore second ls (EXPECT_PASS 'ls | grep 2')
shows just 1, but not 2. i.e. in the affected kernel only second ls failed,
but obviously both should be checked (nobody knows how another bug on cache
invalidation will behave).

I can add the description above to the commit message and adjust the comment in
the file.

Kind regards,
Petr

diff --git testcases/network/nfs/nfs_stress/nfs08.sh testcases/network/nfs/nfs_stress/nfs08.sh
index 8a0f40242..691e221d4 100755
--- testcases/network/nfs/nfs_stress/nfs08.sh
+++ testcases/network/nfs/nfs_stress/nfs08.sh
@@ -2,6 +2,8 @@
 # SPDX-License-Identifier: GPL-2.0-or-later
 # Copyright (c) 2023 Petr Vorel <pvorel@suse.cz>
 # Test reproducer for broken NFS cache invalidation for directories.
+# Kernel patch caused broken cache invalidation, which caused the second 'ls'
+# did not show '2'.
 # Based on reproducer from Neil Brown <neilb@suse.de>
 
 TST_TESTFUNC="do_test"

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

  reply	other threads:[~2023-04-25 13:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-12  8:21 [LTP] [PATCH 1/1] nfs/nfs08.sh: Add test for NFS cache invalidation Petr Vorel
2023-04-12  8:29 ` Petr Vorel
2023-04-25 13:12 ` Cyril Hrubis
2023-04-25 13:48   ` Petr Vorel [this message]
2023-04-26 17:43     ` 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=20230425134845.GA3014439@pevik \
    --to=pvorel@suse.cz \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=neilb@suse.de \
    /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