Re: [PATCH 6.1 00/42] 6.1.15-rc1 review

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Mar 03, 2023 at 02:34:05PM +0530, Naresh Kamboju wrote:
> On Fri, 3 Mar 2023 at 13:34, Paolo Abeni <pabeni@redhat.com> 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@linaro.org> wrote:
> > > >
> > > > On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Thu, Mar 02, 2023 at 03:49:31PM +0530, Naresh Kamboju wrote:
> > > > > > On Wed, 1 Mar 2023 at 23:42, Greg Kroah-Hartman
> > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > This is the start of the stable review cycle for the 6.1.15 release.
> > > > > > > There are 42 patches in this series, all will be posted as a response
> > > > > > > to this one.  If anyone has any issues with these being applied, please
> > > > > > > let me know.
> > > > > > >
> > > > > > > Responses should be made by Fri, 03 Mar 2023 18:06:43 +0000.
> > > > > > > Anything received after that time might be too late.
> > > > > > >
> > > > > > > The whole patch series can be found in one patch at:
> > > > > > >         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.15-rc1.gz
> > > > > > > or in the git tree and branch at:
> > > > > > >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
> > > > > > > and the diffstat can be found below.
> > > > > > >
> > > > > > > thanks,
> > > > > > >
> > > > > > > greg k-h
> > > > > >
> > > > > > Regression found on Linux version 6.1.15-rc1 on 32-bit arm x15 and i386.
> > > > > >
> > > > > > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> > > > > >
> > > > > > ## Build
> > > > > > * kernel: 6.1.15-rc1
> > > > > > * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
> > > > > > * git branch: linux-6.1.y
> > > > > > * git commit: b6150251d4ddf8a80510c185d839631e252e6317
> > > > > > * git describe: v6.1.14-43-gb6150251d4dd
> > > > > > * test details:
> > > > > > https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.14-43-gb6150251d4dd
> > > > > >
> > > > > > Regression test cases,
> > > > > > i386:
> > > > > > x15:
> > > > > >   * kselftest-net-mptcp/net_mptcp_mptcp_sockopt_sh
> > > > > >
> > > > > > # mptcp_sockopt: mptcp_sockopt.c:353: do_getsockopt_tcp_info:
> > > > > > Assertion `ti.d.size_user == sizeof(struct tcp_info)' failed.
> > > > > > # mptcp_sockopt: mptcp_sockopt.c:353: do_getsockopt_tcp_info:
> > > > > > Assertion `ti.d.size_user == sizeof(struct tcp_info)' failed.
> > > > > >
> > > > > > test log:
> > > > > > ----------
> > > > > >
> > > > > > # selftests: net/mptcp: mptcp_sockopt.sh
> > > >
> > > > ....
> > > >
> > > > > Nit, wrapping a log like this makes it hard to read, don't you think?
> > > >
> > > > Me either.
> > > > That is the reason I have shared "Assertion" above.
> > > >
> > > > >
> > > > > > # mptcp_sockopt: mptcp_sockopt.c:353: do_getsockopt_tcp_info:
> > > > > > Assertion `ti.d.size_user == sizeof(struct tcp_info)' failed.
> > > > > > # server killed by signal 6
> > > > > > #
> > > > > > # FAIL: SOL_MPTCP getsockopt
> > > > > > # PASS: TCP_INQ cmsg/ioctl -t tcp
> > > > > > # PASS: TCP_INQ cmsg/ioctl -6 -t tcp
> > > > > > # PASS: TCP_INQ cmsg/ioctl -r tcp
> > > > > > # PASS: TCP_INQ cmsg/ioctl -6 -r tcp
> > > > > > # PASS: TCP_INQ cmsg/ioctl -r tcp -t tcp
> > > > > > not ok 6 selftests: net/mptcp: mptcp_sockopt.sh # exit=1
> > > > >
> > > > > Any chance you can bisect?
> > > >
> > > > 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.)

thanks,

greg k-h