From: Petr Vorel <pvorel@suse.cz>
To: Martin Doucha <mdoucha@suse.cz>
Cc: linux-nfs@vger.kernel.org, NeilBrown <neilb@suse.de>,
Josef Bacik <josef@toxicpanda.com>,
stable@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>,
ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 1/1] nfsstat01: Update client RPC calls for kernel 6.9
Date: Tue, 27 Aug 2024 15:22:42 +0200 [thread overview]
Message-ID: <20240827132242.GA1627011@pevik> (raw)
In-Reply-To: <9afef16d-52b2-435d-902a-7ccfa5824968@suse.cz>
Hi all,
> On 23. 08. 24 23:59, NeilBrown wrote:
> > On Fri, 23 Aug 2024, Petr Vorel wrote:
> > > 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)
> > I don't understand. What exactly do you mean by "the new
> > functionality".
> > As I understand it there is no new functionality. All there was was and
> > information leak between network namespaces, and we stopped the leak.
> > Do you consider that to be new functionality?
Thanks Martin for jumping in. I hoped I was clear, but obviously not.
Following are the questions for kernel maintainers and developers. I put my
opinion, but it's really up to you what you want to have tested.
> The new functionality is that the patches add a new file to network
> namespaces: /proc/net/rpc/nfs. This file did not exist outside the root
> network namespace at least on some of the kernels where we still need to run
> this test. So the question is: How aggressively do we want to enforce
> backporting of these NFS patches into distros with older kernels?
> We have 3 options how to fix the test depending on the answer:
> 1) Don't enforce at all. We'll check whether /proc/net/rpc/nfs exists in the
> client namespace and read it only if it does. Otherwise we'll fall back on
> the global file.
1) is IMHO the worst case because it's not testing patch gets reverted.
> 2) Enforce aggressively. We'll hardcode a minimal kernel version into the
> test (e.g. v5.4) and if the procfile doesn't exist on any newer kernel, it's
> a bug.
I would prefer 2), which is the usual LTP approach (do not hide bugs, we even
fail on upstream kernel WONTFIX [1], why we should refuse the policy here?).
Whichever older LTS upstream kernel gets fixed would drive the line where new
functionality is requested (currently v5.14, I suppose at least 5.10 will also
be fixed). LTP also has a way to specify enterprise distro kernel version if
older enterprise kernel also gets fixed (this should not be needed, but it'd be
possible).
> 3) Enforce on new kernels only. We'll set a hard requirement for kernel
> v6.9+ as in option 2) and check for existence of the procfile on any older
> kernels as in option 1).
Due way to specify enterprise distro kernel version and upstream kernel testing
expecting people update to the latest stable/LTS we should not worry much about
people with older kernels.
Kind regards,
Petr
[1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ustat/ustat01.c#L48-L49
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-08-27 13:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-14 8:57 [LTP] [PATCH v2 1/1] nfsstat01: Update client RPC calls for kernel 6.9 Petr Vorel
2024-08-14 13:13 ` Chuck Lever via ltp
2024-08-23 6:46 ` Petr Vorel
2024-08-23 13:58 ` Chuck Lever III via ltp
2024-08-23 18:53 ` Petr Vorel
2024-08-24 14:54 ` Chuck Lever via ltp
2024-08-23 21:59 ` NeilBrown
2024-08-27 11:49 ` Martin Doucha
2024-08-27 13:22 ` Petr Vorel [this message]
2024-08-27 14:27 ` Chuck Lever III via ltp
2024-08-27 15:27 ` Petr Vorel
2024-08-27 21:09 ` NeilBrown
2024-08-28 8:24 ` 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=20240827132242.GA1627011@pevik \
--to=pvorel@suse.cz \
--cc=chuck.lever@oracle.com \
--cc=josef@toxicpanda.com \
--cc=linux-nfs@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=mdoucha@suse.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox