[LTP] [PATCH v2 1/1] nfsstat01: Update client RPC calls for kernel 6.9

[Chuck Lever III]

> On Aug 27, 2024, at 9:22 AM, Petr Vorel <pvorel@suse.cz> wrote:
> 
> 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?).

2) makes sense to me.


> 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


--
Chuck Lever