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
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 6.1.15-rc1
Alan Stern <[email protected]>
USB: core: Don't hold device lock while reading the "descriptors" sysfs file
Carlos Llamas <[email protected]>
scripts/tags.sh: fix incompatibility with PCRE2
Christian Brauner <[email protected]>
fs: use consistent setgid checks in is_sxid()
Christian Brauner <[email protected]>
attr: use consistent sgid stripping checks
Christian Brauner <[email protected]>
attr: add setattr_should_drop_sgid()
Christian Brauner <[email protected]>
fs: move should_remove_suid()
Christian Brauner <[email protected]>
attr: add in_group_or_capable()
Stylon Wang <[email protected]>
drm/amd/display: Properly reuse completion structure
Saranya Gopal <[email protected]>
usb: typec: pd: Remove usb_suspend_supported sysfs from sink PDO
Kunihiko Hayashi <[email protected]>
arm64: dts: uniphier: Fix property name in PXs3 USB node
Prashanth K <[email protected]>
usb: gadget: u_serial: Add null pointer check in gserial_resume
Florian Zumbiehl <[email protected]>
USB: serial: option: add support for VW/Skoda "Carstick LTE"
Heikki Krogerus <[email protected]>
usb: dwc3: pci: add support for the Intel Meteor Lake-M
Stylon Wang <[email protected]>
drm/amd/display: Fix race condition in DPIA AUX transfer
Nicholas Kazlauskas <[email protected]>
drm/amd/display: Move DCN314 DOMAIN power control to DMCUB
Thomas Weißschuh <[email protected]>
vc_screen: don't clobber return value in vcs_read
Kuniyuki Iwashima <[email protected]>
net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues().
Martin KaFai Lau <[email protected]>
bpf: bpf_fib_lookup should not return neigh in NUD_FAILED state
Rafael J. Wysocki <[email protected]>
PM: sleep: Avoid using pr_cont() in the tasks freezing code
Kan Liang <[email protected]>
x86/cpu: Add Lunar Lake M
Vladimir Oltean <[email protected]>
selftests: ocelot: tc_flower_chains: make test_vlan_ingress_modify() more comprehensive
Luka Guzenko <[email protected]>
HID: Ignore battery for ELAN touchscreen 29DF on HP
Alexey Firago <[email protected]>
ASoC: codecs: es8326: Fix DTS properties reading
Xin Zhao <[email protected]>
HID: core: Fix deadloop in hid_apply_multiplier.
Julian Anastasov <[email protected]>
neigh: make sure used and confirmed times are valid
Dmitry Torokhov <[email protected]>
ARM: dts: stihxxx-b2120: fix polarity of reset line of tsin0 port
V sujith kumar Reddy <[email protected]>
ASoC: SOF: amd: Fix for handling spurious interrupts from DSP
Michael Ellerman <[email protected]>
powerpc: Don't select ARCH_WANTS_NO_INSTR
Dean Luick <[email protected]>
IB/hfi1: Assign npages earlier
Jack Yu <[email protected]>
ASoC: rt715-sdca: fix clock stop prepare timeout issue
Krzysztof Kozlowski <[email protected]>
arm64: dts: rockchip: align rk3399 DMC OPP table with bindings
David Sterba <[email protected]>
btrfs: send: limit number of clones and allocated memory size
Mario Limonciello <[email protected]>
pinctrl: amd: Fix debug output for debounce time
Vishal Verma <[email protected]>
ACPI: NFIT: fix a potential deadlock during NFIT teardown
[email protected] <[email protected]>
HID: Ignore battery for Elan touchscreen on Asus TP420IA
Takahiro Fujii <[email protected]>
HID: elecom: add support for TrackBall 056E:011C
Jonas Karlman <[email protected]>
arm64: dts: rockchip: fix probe of analog sound card on rock-3a
Jensen Huang <[email protected]>
arm64: dts: rockchip: add missing #interrupt-cells to rk356x pcie2x1
Johan Jonker <[email protected]>
ARM: dts: rockchip: add power-domains property to dp node on rk3288
Krzysztof Kozlowski <[email protected]>
arm64: dts: rockchip: drop unused LED mode property from rk3328-roc-cc
Jarrah Gosbell <[email protected]>
arm64: dts: rockchip: reduce thermal limits on rk3399-pinephone-pro
Benedict Wong <[email protected]>
Fix XFRM-I support for nested ESP tunnels
-------------
Diffstat:
Documentation/trace/ftrace.rst | 2 +-
Makefile | 4 +-
arch/arm/boot/dts/rk3288.dtsi | 1 +
arch/arm/boot/dts/stihxxx-b2120.dtsi | 2 +-
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 2 -
arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 2 +-
.../boot/dts/rockchip/rk3399-pinephone-pro.dts | 7 +
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts | 2 +
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 1 +
.../dts/socionext/uniphier-pxs3-ref-gadget0.dts | 2 +-
.../dts/socionext/uniphier-pxs3-ref-gadget1.dts | 2 +-
arch/powerpc/Kconfig | 1 -
arch/x86/include/asm/intel-family.h | 2 +
drivers/acpi/nfit/core.c | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 150 ++++++++++-----------
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 17 ++-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 10 +-
.../gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.c | 24 ++++
.../gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.h | 2 +
.../gpu/drm/amd/display/dc/dcn314/dcn314_init.c | 2 +-
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 25 ++++
drivers/hid/hid-core.c | 3 +
drivers/hid/hid-elecom.c | 16 ++-
drivers/hid/hid-ids.h | 5 +-
drivers/hid/hid-input.c | 4 +
drivers/hid/hid-quirks.c | 3 +-
drivers/infiniband/hw/hfi1/user_exp_rcv.c | 9 +-
drivers/pinctrl/pinctrl-amd.c | 1 +
drivers/tty/vt/vc_screen.c | 7 +-
drivers/usb/core/hub.c | 5 +-
drivers/usb/core/sysfs.c | 5 -
drivers/usb/dwc3/dwc3-pci.c | 4 +
drivers/usb/gadget/function/u_serial.c | 23 +++-
drivers/usb/serial/option.c | 4 +
drivers/usb/typec/pd.c | 1 -
fs/attr.c | 74 +++++++++-
fs/btrfs/send.c | 6 +-
fs/fuse/file.c | 2 +-
fs/inode.c | 64 ++++-----
fs/internal.h | 10 +-
fs/ocfs2/file.c | 4 +-
fs/open.c | 8 +-
include/linux/fs.h | 4 +-
kernel/power/process.c | 21 ++-
net/caif/caif_socket.c | 1 +
net/core/filter.c | 4 +-
net/core/neighbour.c | 18 ++-
net/core/stream.c | 1 -
net/xfrm/xfrm_interface.c | 54 +++++++-
net/xfrm/xfrm_policy.c | 3 +
scripts/tags.sh | 2 +-
sound/soc/codecs/es8326.c | 6 +-
sound/soc/codecs/rt715-sdca-sdw.c | 2 +-
sound/soc/sof/amd/acp.c | 36 +++--
.../drivers/net/ocelot/tc_flower_chains.sh | 2 +-
55 files changed, 446 insertions(+), 228 deletions(-)
On Wed, Mar 01, 2023 at 07:08:21PM +0100, Greg Kroah-Hartman 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.
On our RISC-V stuff, LGTM:
Tested-by: Conor Dooley <[email protected]>
Thanks,
Conor.
On 3/1/2023 10:08 AM, Greg Kroah-Hartman 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
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <[email protected]>
--
Florian
On Wed, Mar 01, 2023 at 07:08:21PM +0100, Greg Kroah-Hartman 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
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le,
s390x, x86_64), and boot tested x86_64. No regressions noted.
Tested-by: Justin M. Forbes <[email protected]>
On 3/1/23 11:08, Greg Kroah-Hartman 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
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
On Wed, Mar 01, 2023 at 07:08:21PM +0100, Greg Kroah-Hartman 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.
>
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 10.2.0) and
powerpc (ps3_defconfig, GCC 12.2.0).
Tested-by: Bagas Sanjaya <[email protected]>
--
An old man doll... just what I always wanted! - Clara
On Wed, 01 Mar 2023 19:08:21 +0100, Greg Kroah-Hartman 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
All tests passing for Tegra ...
Test results for stable-v6.1:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
130 tests: 130 pass, 0 fail
Linux version: 6.1.15-rc1-gb6150251d4dd
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <[email protected]>
Jon
On Wed, 1 Mar 2023 at 23:42, Greg Kroah-Hartman
<[email protected]> 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 <[email protected]>
## 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
[ 918.263983] IPv6: ADDRCONF(NETDEV_CHANGE): ns1eth1: link becomes ready
[ 918.398851] IPv6: ADDRCONF(NETDEV_CHANGE): ns1eth2: link becomes ready
[ 918.538987] IPv6: ADDRCONF(NETDEV_CHANGE): ns1eth3: link becomes ready
[ 918.678270] IPv6: ADDRCONF(NETDEV_CHANGE): ns1eth4: link becomes ready
[ 918.800671] audit: type=1325 audit(1677748585.128:33): table=filter
family=2 entries=0 op=xt_register pid=18489 subj=kernel
comm=\"iptables\"
[ 918.813228] audit: type=1300 audit(1677748585.128:33):
arch=40000003 syscall=102 success=yes exit=0 a0=f a1=bf94ed3c a2=40
a3=b7edfe3c items=0 ppid=18412 pid=18489 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295
comm=\"iptables\" exe=\"/usr/sbin/xtables-legacy-multi\" subj=kernel
key=(null)
[ 918.842987] audit: type=1327 audit(1677748585.128:33):
proctitle=69707461626C6573002D41004F5554505554002D7000746370002D2D73796E002D6D006D61726B002D2D6D61726B0031002D6A00414343455054
[ 918.859285] audit: type=1325 audit(1677748585.128:34): table=filter
family=2 entries=4 op=xt_replace pid=18489 subj=kernel
comm=\"iptables\"
[ 918.871788] audit: type=1300 audit(1677748585.128:34):
arch=40000003 syscall=102 success=yes exit=0 a0=e a1=bf94ef64 a2=40
a3=b7edfe3c items=0 ppid=18412 pid=18489 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295
comm=\"iptables\" exe=\"/usr/sbin/xtables-legacy-multi\" subj=kernel
key=(null)
[ 918.901496] audit: type=1327 audit(1677748585.128:34):
proctitle=69707461626C6573002D41004F5554505554002D7000746370002D2D73796E002D6D006D61726B002D2D6D61726B0031002D6A00414343455054
[ 918.934555] audit: type=1325 audit(1677748585.262:35): table=filter
family=2 entries=5 op=xt_replace pid=18490 subj=kernel
comm=\"iptables\"
[ 918.947242] audit: type=1300 audit(1677748585.262:35):
arch=40000003 syscall=102 success=yes exit=0 a0=e a1=bfc21cd4 a2=40
a3=b7f27e3c items=0 ppid=18412 pid=18490 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295
comm=\"iptables\" exe=\"/usr/sbin/xtables-legacy-multi\" subj=kernel
key=(null)
[ 918.976905] audit: type=1327 audit(1677748585.262:35):
proctitle=69707461626C6573002D41004F5554505554002D7000746370002D2D7463702D666C6167730052535400525354002D6D006D61726B002D2D6D61726B0030002D6A00414343455054
[ 919.013445] audit: type=1325 audit(1677748585.341:36): table=filter
family=2 entries=6 op=xt_replace pid=18491 subj=kernel
comm=\"iptables\"
# Created /tmp/tmp.CG4evZjYl7 (size 1 KB) containing data sent by client
# Created /tmp/tmp.urARJfNrFp (size 1 KB) containing data sent by server
# PASS: all packets had packet mark set
# mptcp_[ 944.426054] kauditd_printk_skb: 50 callbacks suppressed
sockopt: mptcp_s[ 944.426057] audit: type=1701
audit(1677748610.753:53): auid=4294967295 uid=0 gid=0 ses=4294967295
subj=kernel pid=18532 comm=\"mptcp_sockopt\"
exe=\"/opt/kselftests/default-in-kernel/net/mptcp/mptcp_sockopt\"
sig=6 res=1
[ 944.452415] audit: type=1701 audit(1677748610.753:54):
auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=18533
comm=\"mptcp_sockopt\"
exe=\"/opt/kselftests/default-in-kernel/net/mptcp/mptcp_sockopt\"
sig=6 res=1
ockopt.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.
# 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
Test results comparision link,
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.14-43-gb6150251d4dd/testrun/15204254/suite/kselftest-net-mptcp/test/net_mptcp_mptcp_sockopt_sh/history/?page=1
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.14-43-gb6150251d4dd/testrun/15204254/suite/kselftest-net-mptcp/test/net_mptcp_mptcp_sockopt_sh/details/
https://lkft.validation.linaro.org/scheduler/job/6211923#L2664
--
Linaro LKFT
https://lkft.linaro.org
On Thu, Mar 02, 2023 at 03:49:31PM +0530, Naresh Kamboju wrote:
> On Wed, 1 Mar 2023 at 23:42, Greg Kroah-Hartman
> <[email protected]> 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 <[email protected]>
>
> ## 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
> [ 918.263983] IPv6: ADDRCONF(NETDEV_CHANGE): ns1eth1: link becomes ready
> [ 918.398851] IPv6: ADDRCONF(NETDEV_CHANGE): ns1eth2: link becomes ready
> [ 918.538987] IPv6: ADDRCONF(NETDEV_CHANGE): ns1eth3: link becomes ready
> [ 918.678270] IPv6: ADDRCONF(NETDEV_CHANGE): ns1eth4: link becomes ready
> [ 918.800671] audit: type=1325 audit(1677748585.128:33): table=filter
> family=2 entries=0 op=xt_register pid=18489 subj=kernel
> comm=\"iptables\"
> [ 918.813228] audit: type=1300 audit(1677748585.128:33):
> arch=40000003 syscall=102 success=yes exit=0 a0=f a1=bf94ed3c a2=40
> a3=b7edfe3c items=0 ppid=18412 pid=18489 auid=4294967295 uid=0 gid=0
> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295
> comm=\"iptables\" exe=\"/usr/sbin/xtables-legacy-multi\" subj=kernel
> key=(null)
> [ 918.842987] audit: type=1327 audit(1677748585.128:33):
> proctitle=69707461626C6573002D41004F5554505554002D7000746370002D2D73796E002D6D006D61726B002D2D6D61726B0031002D6A00414343455054
> [ 918.859285] audit: type=1325 audit(1677748585.128:34): table=filter
> family=2 entries=4 op=xt_replace pid=18489 subj=kernel
> comm=\"iptables\"
> [ 918.871788] audit: type=1300 audit(1677748585.128:34):
> arch=40000003 syscall=102 success=yes exit=0 a0=e a1=bf94ef64 a2=40
> a3=b7edfe3c items=0 ppid=18412 pid=18489 auid=4294967295 uid=0 gid=0
> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295
> comm=\"iptables\" exe=\"/usr/sbin/xtables-legacy-multi\" subj=kernel
> key=(null)
> [ 918.901496] audit: type=1327 audit(1677748585.128:34):
> proctitle=69707461626C6573002D41004F5554505554002D7000746370002D2D73796E002D6D006D61726B002D2D6D61726B0031002D6A00414343455054
> [ 918.934555] audit: type=1325 audit(1677748585.262:35): table=filter
> family=2 entries=5 op=xt_replace pid=18490 subj=kernel
> comm=\"iptables\"
> [ 918.947242] audit: type=1300 audit(1677748585.262:35):
> arch=40000003 syscall=102 success=yes exit=0 a0=e a1=bfc21cd4 a2=40
> a3=b7f27e3c items=0 ppid=18412 pid=18490 auid=4294967295 uid=0 gid=0
> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295
> comm=\"iptables\" exe=\"/usr/sbin/xtables-legacy-multi\" subj=kernel
> key=(null)
> [ 918.976905] audit: type=1327 audit(1677748585.262:35):
> proctitle=69707461626C6573002D41004F5554505554002D7000746370002D2D7463702D666C6167730052535400525354002D6D006D61726B002D2D6D61726B0030002D6A00414343455054
> [ 919.013445] audit: type=1325 audit(1677748585.341:36): table=filter
> family=2 entries=6 op=xt_replace pid=18491 subj=kernel
> comm=\"iptables\"
> # Created /tmp/tmp.CG4evZjYl7 (size 1 KB) containing data sent by client
> # Created /tmp/tmp.urARJfNrFp (size 1 KB) containing data sent by server
> # PASS: all packets had packet mark set
> # mptcp_[ 944.426054] kauditd_printk_skb: 50 callbacks suppressed
> sockopt: mptcp_s[ 944.426057] audit: type=1701
> audit(1677748610.753:53): auid=4294967295 uid=0 gid=0 ses=4294967295
> subj=kernel pid=18532 comm=\"mptcp_sockopt\"
> exe=\"/opt/kselftests/default-in-kernel/net/mptcp/mptcp_sockopt\"
> sig=6 res=1
> [ 944.452415] audit: type=1701 audit(1677748610.753:54):
> auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=18533
> comm=\"mptcp_sockopt\"
> exe=\"/opt/kselftests/default-in-kernel/net/mptcp/mptcp_sockopt\"
> sig=6 res=1
> ockopt.c:353: do_getsockopt_tcp_info: Assertion `ti.d.size_user ==
> sizeof(struct tcp_info)' failed.
Nit, wrapping a log like this makes it hard to read, don't you think?
> # 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?
And is this an issue on 6.2 and/or Linus's tree? I don't see any mptcp
changes in this 6.1-rc cycle, they were in the last one...
thanks,
greg k-h
On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman
<[email protected]> 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
> > <[email protected]> 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 <[email protected]>
> >
> > ## 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.
>
> And is this an issue on 6.2 and/or Linus's tree?
Not seen on Linux mainline, next and 6.2.
> I don't see any mptcp
> changes in this 6.1-rc cycle, they were in the last one...
>
> thanks,
>
> greg k-h
Hi Greg,
On Wed, Mar 01, 2023 at 07:08:21PM +0100, Greg Kroah-Hartman 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.
Build test (gcc version 12.2.1 20230210):
mips: 52 configs -> no failure
arm: 100 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/2975
[2]. https://openqa.qa.codethink.co.uk/tests/2981
[3]. https://openqa.qa.codethink.co.uk/tests/2983
Tested-by: Sudip Mukherjee <[email protected]>
--
Regards
Sudip
On Thu, 2 Mar 2023 at 16:30, Naresh Kamboju <[email protected]> wrote:
>
> On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman
> <[email protected]> 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
> > > <[email protected]> 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 <[email protected]>
> > >
> > > ## 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.
Tested-by: Linux Kernel Functional Testing <[email protected]>
## 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
--
Linaro LKFT
https://lkft.linaro.org
On 3/1/23 13:08, Greg Kroah-Hartman 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.
6.1.15-rc1 compiled and booted on my x86_64 test system. No errors or regressions.
Tested-by: Slade Watkins <[email protected]>
-- Slade
On Wed, Mar 01, 2023 at 07:08:21PM +0100, Greg Kroah-Hartman 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.
Hi Greg,
6.1.15-rc1 tested.
Run tested on:
- Allwinner H6 (Tanix TX6)
- Intel Alder Lake x86_64 (nuc12 i7-1260P)
In addition - build tested for:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos
Tested-by: Rudi Heitbaum <[email protected]>
--
Rudi
On Wed, Mar 01, 2023 at 07:08:21PM +0100, Greg Kroah-Hartman 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.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 503 pass: 503 fail: 0
Tested-by: Guenter Roeck <[email protected]>
Guenter
On 3/1/23 10:08 AM, Greg Kroah-Hartman 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
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Tested-by: Ron Economos <[email protected]>
On Fri, Mar 03, 2023 at 01:32:47AM +0530, Naresh Kamboju wrote:
> On Thu, 2 Mar 2023 at 16:30, Naresh Kamboju <[email protected]> wrote:
> >
> > On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman
> > <[email protected]> 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
> > > > <[email protected]> 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 <[email protected]>
> > > >
> > > > ## 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.
Where is this problem reported? Is this a 6.2 test checking for
something that is not in 6.1?
thanks,
greg k-h
Hello,
On Fri, 2023-03-03 at 01:32 +0530, Naresh Kamboju wrote:
> On Thu, 2 Mar 2023 at 16:30, Naresh Kamboju <[email protected]> wrote:
> >
> > On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman
> > <[email protected]> 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
> > > > <[email protected]> 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 <[email protected]>
> > > >
> > > > ## 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? If so failures are expected;
please use the self-tests and kernel from the same release.
Otherwise, could you please re-phrase the above?
Thanks,
Paolo
On Fri, 3 Mar 2023 at 12:31, Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Fri, Mar 03, 2023 at 01:32:47AM +0530, Naresh Kamboju wrote:
> > On Thu, 2 Mar 2023 at 16:30, Naresh Kamboju <[email protected]> wrote:
> > >
> > > On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman
> > > <[email protected]> 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
> > > > > <[email protected]> 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 <[email protected]>
> > > > >
> > > > > ## 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.
>
> Where is this problem reported?
We have been running most recent stable (6.2) selftest sources on
older stable-rc branches ( 6.1 ... 4.14).
> Is this a 6.2 test checking for
> something that is not in 6.1?
mptcp developers might have a better idea,
- Naresh
On Fri, 3 Mar 2023 at 13:34, Paolo Abeni <[email protected]> wrote:
>
> Hello,
>
> On Fri, 2023-03-03 at 01:32 +0530, Naresh Kamboju wrote:
> > On Thu, 2 Mar 2023 at 16:30, Naresh Kamboju <[email protected]> wrote:
> > >
> > > On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman
> > > <[email protected]> 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
> > > > > <[email protected]> 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 <[email protected]>
> > > > >
> > > > > ## 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;
Thanks for clarifying this.
> please use the self-tests and kernel from the same release.
>
> Otherwise, could you please re-phrase the above?
>
> Thanks,
>
> Paolo
>
- Naresh
On Fri, Mar 03, 2023 at 02:34:05PM +0530, Naresh Kamboju wrote:
> On Fri, 3 Mar 2023 at 13:34, Paolo Abeni <[email protected]> wrote:
> >
> > Hello,
> >
> > On Fri, 2023-03-03 at 01:32 +0530, Naresh Kamboju wrote:
> > > On Thu, 2 Mar 2023 at 16:30, Naresh Kamboju <[email protected]> wrote:
> > > >
> > > > On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman
> > > > <[email protected]> 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
> > > > > > <[email protected]> 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 <[email protected]>
> > > > > >
> > > > > > ## 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
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 <[email protected]>:
> On Fri, Mar 03, 2023 at 02:34:05PM +0530, Naresh Kamboju wrote:
>> On Fri, 3 Mar 2023 at 13:34, Paolo Abeni <[email protected]> wrote:
>>>
>>> Hello,
>>>
>>> On Fri, 2023-03-03 at 01:32 +0530, Naresh Kamboju wrote:
>>>> On Thu, 2 Mar 2023 at 16:30, Naresh Kamboju <[email protected]> wrote:
>>>>>
>>>>> On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman
>>>>> <[email protected]> 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
http://www.tessares.net
On Fri, Mar 03, 2023 at 10:47:33AM +0100, Matthieu Baerts wrote:
> 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 <[email protected]>:
>
> > On Fri, Mar 03, 2023 at 02:34:05PM +0530, Naresh Kamboju wrote:
> >> On Fri, 3 Mar 2023 at 13:34, Paolo Abeni <[email protected]> wrote:
> >>>
> >>> Hello,
> >>>
> >>> On Fri, 2023-03-03 at 01:32 +0530, Naresh Kamboju wrote:
> >>>> On Thu, 2 Mar 2023 at 16:30, Naresh Kamboju <[email protected]> wrote:
> >>>>>
> >>>>> On Thu, 2 Mar 2023 at 16:00, Greg Kroah-Hartman
> >>>>> <[email protected]> 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.
"Features" are not usually limited to specific kernel versions (think
about the mess that "enterprise" kernels create by backports). And if
they are, running a userspace test should be able to detect if the
feature is present or not by the error returned to it, right? If not,
then the feature is mis-designed.
> That's how we thought we should design MPTCP selftests. Maybe we need to change this design?
Yes, please "skip" tests for features that are just not present, do not
fail them.
> Is it a common practice to run selftests' latest version on older kernels?
Yes.
thanks,
greg k-h
Hi Greg,
3 Mar 2023 11:26:46 Greg Kroah-Hartman <[email protected]>:
> On Fri, Mar 03, 2023 at 10:47:33AM +0100, Matthieu Baerts wrote:
>> 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 <[email protected]>:
>>
>>> On Fri, Mar 03, 2023 at 02:34:05PM +0530, Naresh Kamboju wrote:
>>>> On Fri, 3 Mar 2023 at 13:34, Paolo Abeni <[email protected]> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> On Fri, 2023-03-03 at 01:32 +0530, Naresh Kamboju wrote:
>>>>>> …
>>>>>
>>>>> 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.
>
> "Features" are not usually limited to specific kernel versions (think
> about the mess that "enterprise" kernels create by backports). And if
> they are, running a userspace test should be able to detect if the
> feature is present or not by the error returned to it, right? If not,
> then the feature is mis-designed.
Thank you for the explanation. (I didn't know these tests had to support "enterprise" kernels.)
For features where the userspace explicitly asks to use them, that's easy. For events that are only created from a specific kernel version, that will be harder but it is maybe a sign that something else is missing on our side :)
>> That's how we thought we should design MPTCP selftests. Maybe we need to change this design?
>
> Yes, please "skip" tests for features that are just not present, do not
> fail them.
It might take a bit of time but we will look at that. I think we don't even check MPTCP is available before starting the first test, we just assume it is there if someone explicitly starts these tests :-)
>> Is it a common practice to run selftests' latest version on older kernels?
>
> Yes.
Thank you, I didn't know (and I don't know if it is well known by kernel devs and maintainers).
Cheers,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
http://www.tessares.net
On Fri, Mar 03, 2023 at 11:56:26AM +0100, Matthieu Baerts wrote:
> Hi Greg,
>
> 3 Mar 2023 11:26:46 Greg Kroah-Hartman <[email protected]>:
>
> > On Fri, Mar 03, 2023 at 10:47:33AM +0100, Matthieu Baerts wrote:
> >> 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 <[email protected]>:
> >>
> >>> On Fri, Mar 03, 2023 at 02:34:05PM +0530, Naresh Kamboju wrote:
> >>>> On Fri, 3 Mar 2023 at 13:34, Paolo Abeni <[email protected]> wrote:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> On Fri, 2023-03-03 at 01:32 +0530, Naresh Kamboju wrote:
> >>>>>> …
> >>>>>
> >>>>> 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.
> >
> > "Features" are not usually limited to specific kernel versions (think
> > about the mess that "enterprise" kernels create by backports). And if
> > they are, running a userspace test should be able to detect if the
> > feature is present or not by the error returned to it, right? If not,
> > then the feature is mis-designed.
>
> Thank you for the explanation. (I didn't know these tests had to support "enterprise" kernels.)
Tests have to run anywhere.
> For features where the userspace explicitly asks to use them, that's easy. For events that are only created from a specific kernel version, that will be harder but it is maybe a sign that something else is missing on our side :)
Think about userspace, how will it even know if a feature is present or
not in the kernel it is running on? It needs to know "I tried to use
this and it failed because of it not being there or because something
else went wrong". Userspace has to be able to distinguish between the
two somehow, otherwise no one will be able to use your feature very
well.
So just rewrite the test to handle "not present", like we can handle
ioctls or syscalls not being present vs. "an error happened".
> >> That's how we thought we should design MPTCP selftests. Maybe we need to change this design?
> >
> > Yes, please "skip" tests for features that are just not present, do not
> > fail them.
>
> It might take a bit of time but we will look at that. I think we don't
> even check MPTCP is available before starting the first test, we just
> assume it is there if someone explicitly starts these tests :-)
That too should probably be fixed up :)
thanks,
greg k-h
On Fri, 2023-03-03 at 10:23 +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 03, 2023 at 02:34:05PM +0530, Naresh Kamboju wrote:
> > On Fri, 3 Mar 2023 at 13:34, Paolo Abeni <[email protected]> wrote:
> > > 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?
I was not aware that running self-tests on older kernels is a common
practice. I'm surprised that hits mptcp specifically. I think most
networking tests have the same problem.
Additionally, some self-tests check for known bugs/regressions. Running
them on older kernel will cause real trouble, and checking for bug
presence in the running kernel would be problematic at best, I think.
> 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.)
I don't understand this later part, could you please re-phrase?
Users should look at release notes and/or official documentation to
know the supported features, not to self-tests output ?!?
Thanks!
Paolo
p.s. for some reasons I did not receive the previous replies, I had to
fetch the conversation from the ML archives.
On Fri, Mar 03, 2023 at 12:39:07PM +0100, Paolo Abeni wrote:
> On Fri, 2023-03-03 at 10:23 +0100, Greg Kroah-Hartman wrote:
> > On Fri, Mar 03, 2023 at 02:34:05PM +0530, Naresh Kamboju wrote:
> > > On Fri, 3 Mar 2023 at 13:34, Paolo Abeni <[email protected]> wrote:
> > > > 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? ?
>
> I was not aware that running self-tests on older kernels is a common
> practice. I'm surprised that hits mptcp specifically. I think most
> networking tests have the same problem.
>
> Additionally, some self-tests check for known bugs/regressions. Running
> them on older kernel will cause real trouble, and checking for bug
> presence in the running kernel would be problematic at best, I think.
No, not at all, why wouldn't you want to test for know bugs and
regressions and fail? That's a great thing to do, and so you will know
to backport those bugfixes to those older kernels if you have to use
them.
> > 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.)
>
> I don't understand this later part, could you please re-phrase?
>
> Users should look at release notes and/or official documentation to
> know the supported features, not to self-tests output ?!?
How can a program "read a release note"?
Features in the kernel should be able to be detected if they are present
or not, in some way, right? Syscalls work this way, as does sysfs
entries and other ways of interacting with the kernel.
If there is no way for a program to "know" if a feature is present or
not, how can it detect the difference between "this failed because of
something I did wrong", vs. "this failed because it is not present in
this kernel at all".
thanks,
greg k-h
On Fri, 2023-03-03 at 12:44 +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 03, 2023 at 12:39:07PM +0100, Paolo Abeni wrote:
> > Additionally, some self-tests check for known bugs/regressions. Running
> > them on older kernel will cause real trouble, and checking for bug
> > presence in the running kernel would be problematic at best, I think.
>
> No, not at all, why wouldn't you want to test for know bugs and
> regressions and fail? That's a great thing to do, and so you will know
> to backport those bugfixes to those older kernels if you have to use
> them.
I'm sorry, I likely was not clear at all. What I mean is that the self-
test for a bug may trigger e.g. memory corruption on the bugged kernel
(or more specifically to networking, the infamous, recurring
"unregister_netdevice: waiting for ...") which in turn could cause
random failures later.
If that specific case runs on older (unpatched) kernel will screw the
overall tests results. The same could happen in less-detectable way for
old bugs non explicitly checked by any test, but still triggered by the
test-suite. As a consequence I expect that the results observed running
newer self-tests on older kernel are unreliable.
Cheers,
Paolo
On Fri, Mar 03, 2023 at 01:41:00PM +0100, Paolo Abeni wrote:
> On Fri, 2023-03-03 at 12:44 +0100, Greg Kroah-Hartman wrote:
> > On Fri, Mar 03, 2023 at 12:39:07PM +0100, Paolo Abeni wrote:
> > > Additionally, some self-tests check for known bugs/regressions. Running
> > > them on older kernel will cause real trouble, and checking for bug
> > > presence in the running kernel would be problematic at best, I think.
> >
> > No, not at all, why wouldn't you want to test for know bugs and
> > regressions and fail? That's a great thing to do, and so you will know
> > to backport those bugfixes to those older kernels if you have to use
> > them.
>
> I'm sorry, I likely was not clear at all. What I mean is that the self-
> test for a bug may trigger e.g. memory corruption on the bugged kernel
> (or more specifically to networking, the infamous, recurring
> "unregister_netdevice: waiting for ...") which in turn could cause
> random failures later.
>
> If that specific case runs on older (unpatched) kernel will screw the
> overall tests results. The same could happen in less-detectable way for
> old bugs non explicitly checked by any test, but still triggered by the
> test-suite. As a consequence I expect that the results observed running
> newer self-tests on older kernel are unreliable.
For the stable/LTS kernel trees, they should _never_ be unreliable,
otherwise that means we have missed a needed fix and so we need to
resolve that.
Which is why I always recommend running the latest selftests on all
older kernels, and have for a very long time now.
thanks,
greg k-h