Hi Greg, Naresh, Paolo, Thank you for the new version and for having reported the issue and running MPTCP selftests! 3 Mar 2023 10:23:06 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>: > On Fri, Mar 03, 2023 at 02:34:05PM +0530, Naresh Kamboju wrote: >> On Fri, 3 Mar 2023 at 13:34, Paolo Abeni <pabeni@xxxxxxxxxx> wrote: >>> >>> Hello, >>> >>> On Fri, 2023-03-03 at 01:32 +0530, Naresh Kamboju wrote: >>>> On Thu, 2 Mar 2023 at 16:30, Naresh Kamboju <naresh.kamboju@xxxxxxxxxx> wrote: >>>>> >>>>> On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman >>>>> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >>>>>> … >>>>> >>>>> .... >>>>> >>>>>> … >>>>> >>>>> Me either. >>>>> That is the reason I have shared "Assertion" above. >>>>> >>>>>> … >>>>> >>>>> We are running our bisection scripts. >>>> >>>> We have tested with 6.1.14 kselftests source again and it passes. >>>> Now that we have upgraded to 6.2.1 kselftests source, we find that >>>> there is this problem reported. so, not a kernel regression. >>> >>> I read the above as you are running self-tests from 6.2.1 on top of an >>> older (6.1) kernel. Is that correct? >> >> correct. >> >>> If so failures are expected; > > Shouldn't the test be able to know that "new features" are not present > and properly skip the test for when that happens? Otherwise this feels > like a problem going forward as no one will know if this feature can be > used or not (assuming it is a new feature and not just a functional > change.) All MPTCP selftests are designed to run on the same kernel version they are attached to. This allows us to do more checks knowing they are not supposed to fail on newer kernel versions and not being skipped if there is an error when trying to use the new feature. If there are fixes, we make sure the stable team is Cc'ed. If there are API changes, it would be visible because we would need to adapt existing selftests. That's how we thought we should design MPTCP selftests. Maybe we need to change this design? Is it a common practice to run selftests' latest version on older kernels? Cheers, Matt -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net
