Hi all, > > On Aug 27, 2024, at 9:22 AM, Petr Vorel <pvorel@xxxxxxx> 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. Thanks for your opinion. I'll send another version (+ still wait for others input). Kind regards, Petr > > 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
