From: Petr Vorel <pvorel@suse.cz>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: "ltp@lists.linux.it" <ltp@lists.linux.it>,
Li Wang <liwang@redhat.com>, Cyril Hrubis <chrubis@suse.cz>,
Avinesh Kumar <akumar@suse.de>,
Josef Bacik <josef@toxicpanda.com>, Neil Brown <neilb@suse.de>,
linux-stable <stable@vger.kernel.org>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2 1/1] nfsstat01: Update client RPC calls for kernel 6.9
Date: Fri, 23 Aug 2024 20:53:02 +0200 [thread overview]
Message-ID: <20240823185302.GA1302254@pevik> (raw)
In-Reply-To: <0BDD1287-471E-47A8-A362-DF660806CED6@oracle.com>
> > On Aug 23, 2024, at 2:46 AM, Petr Vorel <pvorel@suse.cz> wrote:
> > Hi Chuck, Neil, all,
> >> On Wed, Aug 14, 2024 at 10:57:21AM +0200, Petr Vorel wrote:
> >>> 6.9 moved client RPC calls to namespace in "Make nfs stats visible in
> >>> network NS" patchet.
> >>> https://lore.kernel.org/linux-nfs/cover.1708026931.git.josef@toxicpanda.com/
> >>> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> >>> ---
> >>> Changes v1->v2:
> >>> * Point out whole patchset, not just single commit
> >>> * Add a comment about the patchset
> >>> Hi all,
> >>> could you please ack this so that we have fixed mainline?
> >>> FYI Some parts has been backported, e.g.:
> >>> d47151b79e322 ("nfs: expose /proc/net/sunrpc/nfs in net namespaces")
> >>> to all stable/LTS: 5.4.276, 5.10.217, 5.15.159, 6.1.91, 6.6.31.
> >>> But most of that is not yet (but planned to be backported), e.g.
> >>> 93483ac5fec62 ("nfsd: expose /proc/net/sunrpc/nfsd in net namespaces")
> >>> see Chuck's patchset for 6.6
> >>> https://lore.kernel.org/linux-nfs/20240812223604.32592-1-cel@kernel.org/
> >>> Once all kernels up to 5.4 fixed we should update the version.
> >>> Kind regards,
> >>> Petr
> >>> testcases/network/nfs/nfsstat01/nfsstat01.sh | 9 ++++++++-
> >>> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>> diff --git a/testcases/network/nfs/nfsstat01/nfsstat01.sh b/testcases/network/nfs/nfsstat01/nfsstat01.sh
> >>> index c2856eff1f..1beecbec43 100755
> >>> --- a/testcases/network/nfs/nfsstat01/nfsstat01.sh
> >>> +++ b/testcases/network/nfs/nfsstat01/nfsstat01.sh
> >>> @@ -15,7 +15,14 @@ get_calls()
> >>> local calls opt
> >>> [ "$name" = "rpc" ] && opt="r" || opt="n"
> >>> - ! tst_net_use_netns && [ "$nfs_f" != "nfs" ] && type="rhost"
> >>> +
> >>> + if tst_net_use_netns; then
> >>> + # "Make nfs stats visible in network NS" patchet
> >>> + # https://lore.kernel.org/linux-nfs/cover.1708026931.git.josef@toxicpanda.com/
> >>> + tst_kvcmp -ge "6.9" && [ "$nfs_f" = "nfs" ] && type="rhost"
> >> Hello Petr-
> >> My concern with this fix is it targets v6.9 specifically, yet we
> >> know these fixes will appear in LTS/stable kernels as well.
> > Great! I see you already fixed up to 5.15. I suppose the code is really
> > backportable to the other still active branches (5.10, 5.4, 4.19).
> I plan to work on backporting to v5.10 next week.
> I've been asked to look at v5.4, but I'm not sure how difficult
> that will be because it's missing a lot of NFSD patches. I will
> look into that in a couple of weeks.
> I'm very likely to punt on v4.19, though Oracle's stable backport
> team might try to tackle it at some point. (pun intended)
Thanks a lot for info, we'll see what you / your Oracle backport team will
manage in the end.
> > We discussed in v1 how to fix tests. Neil suggested to fix the test the way so
> > that it works on all kernels. As I note [1]
> > 1) either we give up on checking the new functionality still works (if we
> > fallback to old behavior)
> > 2) or we need to specify from which kernel we expect new functionality
> > (so far it's 5.15, I suppose it will be older).
> > I would prefer 2) to have new functionality always tested.
> > Or am I missing something obvious?
> I don't quite understand the question.
> The "old functionality" of reporting these statistics globally
> is broken, but we're stuck with it in the older kernels. I guess
> you might want to confirm that, for a given recent kernel
> release, the stats are actually per-namespace -- that's what we
> expect in fixed kernels. Is that what you mean?
Yes. I'm just trying to say that Neil's proposal "work everywhere without
checking kernel version" will not work. I would like next week, after you send
5.10 patches to expect anything >= 5.10 will have new functionality
and update kernel version if more gets backported.
Kind regards,
Petr
> > Kind regards,
> > Petr
> > [1] https://lore.kernel.org/linux-nfs/172367387549.6062.7078032983644586462@noble.neil.brown.name/
> >> Neil Brown suggested an alternative approach that might not depend
> >> on knowing the specific kernel version:
> >> https://lore.kernel.org/linux-nfs/172078283934.15471.13377048166707693692@noble.neil.brown.name/
> >> HTH
> >>> + else
> >>> + [ "$nfs_f" != "nfs" ] && type="rhost"
> >>> + fi
> >>> if [ "$type" = "lhost" ]; then
> >>> calls="$(grep $name /proc/net/rpc/$nfs_f | cut -d' ' -f$field)"
> >>> --
> >>> 2.45.2
WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Neil Brown <neilb@suse.de>, Josef Bacik <josef@toxicpanda.com>,
linux-stable <stable@vger.kernel.org>,
"ltp@lists.linux.it" <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH v2 1/1] nfsstat01: Update client RPC calls for kernel 6.9
Date: Fri, 23 Aug 2024 20:53:02 +0200 [thread overview]
Message-ID: <20240823185302.GA1302254@pevik> (raw)
In-Reply-To: <0BDD1287-471E-47A8-A362-DF660806CED6@oracle.com>
> > On Aug 23, 2024, at 2:46 AM, Petr Vorel <pvorel@suse.cz> wrote:
> > Hi Chuck, Neil, all,
> >> On Wed, Aug 14, 2024 at 10:57:21AM +0200, Petr Vorel wrote:
> >>> 6.9 moved client RPC calls to namespace in "Make nfs stats visible in
> >>> network NS" patchet.
> >>> https://lore.kernel.org/linux-nfs/cover.1708026931.git.josef@toxicpanda.com/
> >>> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> >>> ---
> >>> Changes v1->v2:
> >>> * Point out whole patchset, not just single commit
> >>> * Add a comment about the patchset
> >>> Hi all,
> >>> could you please ack this so that we have fixed mainline?
> >>> FYI Some parts has been backported, e.g.:
> >>> d47151b79e322 ("nfs: expose /proc/net/sunrpc/nfs in net namespaces")
> >>> to all stable/LTS: 5.4.276, 5.10.217, 5.15.159, 6.1.91, 6.6.31.
> >>> But most of that is not yet (but planned to be backported), e.g.
> >>> 93483ac5fec62 ("nfsd: expose /proc/net/sunrpc/nfsd in net namespaces")
> >>> see Chuck's patchset for 6.6
> >>> https://lore.kernel.org/linux-nfs/20240812223604.32592-1-cel@kernel.org/
> >>> Once all kernels up to 5.4 fixed we should update the version.
> >>> Kind regards,
> >>> Petr
> >>> testcases/network/nfs/nfsstat01/nfsstat01.sh | 9 ++++++++-
> >>> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>> diff --git a/testcases/network/nfs/nfsstat01/nfsstat01.sh b/testcases/network/nfs/nfsstat01/nfsstat01.sh
> >>> index c2856eff1f..1beecbec43 100755
> >>> --- a/testcases/network/nfs/nfsstat01/nfsstat01.sh
> >>> +++ b/testcases/network/nfs/nfsstat01/nfsstat01.sh
> >>> @@ -15,7 +15,14 @@ get_calls()
> >>> local calls opt
> >>> [ "$name" = "rpc" ] && opt="r" || opt="n"
> >>> - ! tst_net_use_netns && [ "$nfs_f" != "nfs" ] && type="rhost"
> >>> +
> >>> + if tst_net_use_netns; then
> >>> + # "Make nfs stats visible in network NS" patchet
> >>> + # https://lore.kernel.org/linux-nfs/cover.1708026931.git.josef@toxicpanda.com/
> >>> + tst_kvcmp -ge "6.9" && [ "$nfs_f" = "nfs" ] && type="rhost"
> >> Hello Petr-
> >> My concern with this fix is it targets v6.9 specifically, yet we
> >> know these fixes will appear in LTS/stable kernels as well.
> > Great! I see you already fixed up to 5.15. I suppose the code is really
> > backportable to the other still active branches (5.10, 5.4, 4.19).
> I plan to work on backporting to v5.10 next week.
> I've been asked to look at v5.4, but I'm not sure how difficult
> that will be because it's missing a lot of NFSD patches. I will
> look into that in a couple of weeks.
> I'm very likely to punt on v4.19, though Oracle's stable backport
> team might try to tackle it at some point. (pun intended)
Thanks a lot for info, we'll see what you / your Oracle backport team will
manage in the end.
> > We discussed in v1 how to fix tests. Neil suggested to fix the test the way so
> > that it works on all kernels. As I note [1]
> > 1) either we give up on checking the new functionality still works (if we
> > fallback to old behavior)
> > 2) or we need to specify from which kernel we expect new functionality
> > (so far it's 5.15, I suppose it will be older).
> > I would prefer 2) to have new functionality always tested.
> > Or am I missing something obvious?
> I don't quite understand the question.
> The "old functionality" of reporting these statistics globally
> is broken, but we're stuck with it in the older kernels. I guess
> you might want to confirm that, for a given recent kernel
> release, the stats are actually per-namespace -- that's what we
> expect in fixed kernels. Is that what you mean?
Yes. I'm just trying to say that Neil's proposal "work everywhere without
checking kernel version" will not work. I would like next week, after you send
5.10 patches to expect anything >= 5.10 will have new functionality
and update kernel version if more gets backported.
Kind regards,
Petr
> > Kind regards,
> > Petr
> > [1] https://lore.kernel.org/linux-nfs/172367387549.6062.7078032983644586462@noble.neil.brown.name/
> >> Neil Brown suggested an alternative approach that might not depend
> >> on knowing the specific kernel version:
> >> https://lore.kernel.org/linux-nfs/172078283934.15471.13377048166707693692@noble.neil.brown.name/
> >> HTH
> >>> + else
> >>> + [ "$nfs_f" != "nfs" ] && type="rhost"
> >>> + fi
> >>> if [ "$type" = "lhost" ]; then
> >>> calls="$(grep $name /proc/net/rpc/$nfs_f | cut -d' ' -f$field)"
> >>> --
> >>> 2.45.2
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-08-23 19:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-14 8:57 [PATCH v2 1/1] nfsstat01: Update client RPC calls for kernel 6.9 Petr Vorel
2024-08-14 8:57 ` [LTP] " Petr Vorel
2024-08-14 13:13 ` Chuck Lever
2024-08-14 13:13 ` [LTP] " Chuck Lever via ltp
2024-08-23 6:46 ` Petr Vorel
2024-08-23 6:46 ` [LTP] " Petr Vorel
2024-08-23 13:58 ` Chuck Lever III
2024-08-23 13:58 ` [LTP] " Chuck Lever III via ltp
2024-08-23 18:53 ` Petr Vorel [this message]
2024-08-23 18:53 ` Petr Vorel
2024-08-24 14:54 ` Chuck Lever
2024-08-24 14:54 ` [LTP] " Chuck Lever via ltp
2024-08-23 21:59 ` NeilBrown
2024-08-23 21:59 ` [LTP] " NeilBrown
2024-08-27 11:49 ` Martin Doucha
2024-08-27 11:49 ` Martin Doucha
2024-08-27 13:22 ` Petr Vorel
2024-08-27 13:22 ` Petr Vorel
2024-08-27 14:27 ` Chuck Lever III
2024-08-27 14:27 ` Chuck Lever III via ltp
2024-08-27 15:27 ` Petr Vorel
2024-08-27 15:27 ` Petr Vorel
2024-08-27 21:09 ` NeilBrown
2024-08-27 21:09 ` NeilBrown
2024-08-28 8:24 ` Petr Vorel
2024-08-28 8:24 ` Petr Vorel
2024-08-14 14:05 ` kernel test robot
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=20240823185302.GA1302254@pevik \
--to=pvorel@suse.cz \
--cc=akumar@suse.de \
--cc=chrubis@suse.cz \
--cc=chuck.lever@oracle.com \
--cc=josef@toxicpanda.com \
--cc=linux-nfs@vger.kernel.org \
--cc=liwang@redhat.com \
--cc=ltp@lists.linux.it \
--cc=neilb@suse.de \
--cc=stable@vger.kernel.org \
/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.