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.... 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 gregkh@linuxfoundation.org Linux 6.1.15-rc1
Alan Stern stern@rowland.harvard.edu USB: core: Don't hold device lock while reading the "descriptors" sysfs file
Carlos Llamas cmllamas@google.com scripts/tags.sh: fix incompatibility with PCRE2
Christian Brauner brauner@kernel.org fs: use consistent setgid checks in is_sxid()
Christian Brauner brauner@kernel.org attr: use consistent sgid stripping checks
Christian Brauner brauner@kernel.org attr: add setattr_should_drop_sgid()
Christian Brauner brauner@kernel.org fs: move should_remove_suid()
Christian Brauner brauner@kernel.org attr: add in_group_or_capable()
Stylon Wang stylon.wang@amd.com drm/amd/display: Properly reuse completion structure
Saranya Gopal saranya.gopal@intel.com usb: typec: pd: Remove usb_suspend_supported sysfs from sink PDO
Kunihiko Hayashi hayashi.kunihiko@socionext.com arm64: dts: uniphier: Fix property name in PXs3 USB node
Prashanth K quic_prashk@quicinc.com usb: gadget: u_serial: Add null pointer check in gserial_resume
Florian Zumbiehl florz@florz.de USB: serial: option: add support for VW/Skoda "Carstick LTE"
Heikki Krogerus heikki.krogerus@linux.intel.com usb: dwc3: pci: add support for the Intel Meteor Lake-M
Stylon Wang stylon.wang@amd.com drm/amd/display: Fix race condition in DPIA AUX transfer
Nicholas Kazlauskas nicholas.kazlauskas@amd.com drm/amd/display: Move DCN314 DOMAIN power control to DMCUB
Thomas Weißschuh linux@weissschuh.net vc_screen: don't clobber return value in vcs_read
Kuniyuki Iwashima kuniyu@amazon.com net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues().
Martin KaFai Lau martin.lau@kernel.org bpf: bpf_fib_lookup should not return neigh in NUD_FAILED state
Rafael J. Wysocki rafael.j.wysocki@intel.com PM: sleep: Avoid using pr_cont() in the tasks freezing code
Kan Liang kan.liang@linux.intel.com x86/cpu: Add Lunar Lake M
Vladimir Oltean vladimir.oltean@nxp.com selftests: ocelot: tc_flower_chains: make test_vlan_ingress_modify() more comprehensive
Luka Guzenko l.guzenko@web.de HID: Ignore battery for ELAN touchscreen 29DF on HP
Alexey Firago a.firago@yadro.com ASoC: codecs: es8326: Fix DTS properties reading
Xin Zhao xnzhao@google.com HID: core: Fix deadloop in hid_apply_multiplier.
Julian Anastasov ja@ssi.bg neigh: make sure used and confirmed times are valid
Dmitry Torokhov dmitry.torokhov@gmail.com ARM: dts: stihxxx-b2120: fix polarity of reset line of tsin0 port
V sujith kumar Reddy Vsujithkumar.Reddy@amd.com ASoC: SOF: amd: Fix for handling spurious interrupts from DSP
Michael Ellerman mpe@ellerman.id.au powerpc: Don't select ARCH_WANTS_NO_INSTR
Dean Luick dean.luick@cornelisnetworks.com IB/hfi1: Assign npages earlier
Jack Yu jack.yu@realtek.com ASoC: rt715-sdca: fix clock stop prepare timeout issue
Krzysztof Kozlowski krzysztof.kozlowski@linaro.org arm64: dts: rockchip: align rk3399 DMC OPP table with bindings
David Sterba dsterba@suse.com btrfs: send: limit number of clones and allocated memory size
Mario Limonciello mario.limonciello@amd.com pinctrl: amd: Fix debug output for debounce time
Vishal Verma vishal.l.verma@intel.com ACPI: NFIT: fix a potential deadlock during NFIT teardown
marco.rodolfi@tuta.io marco.rodolfi@tuta.io HID: Ignore battery for Elan touchscreen on Asus TP420IA
Takahiro Fujii fujii@xaxxi.net HID: elecom: add support for TrackBall 056E:011C
Jonas Karlman jonas@kwiboo.se arm64: dts: rockchip: fix probe of analog sound card on rock-3a
Jensen Huang jensenhuang@friendlyarm.com arm64: dts: rockchip: add missing #interrupt-cells to rk356x pcie2x1
Johan Jonker jbx6244@gmail.com ARM: dts: rockchip: add power-domains property to dp node on rk3288
Krzysztof Kozlowski krzysztof.kozlowski@linaro.org arm64: dts: rockchip: drop unused LED mode property from rk3328-roc-cc
Jarrah Gosbell kernel@undef.tools arm64: dts: rockchip: reduce thermal limits on rk3399-pinephone-pro
Benedict Wong benedictwong@google.com 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.... 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 conor.dooley@microchip.com
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.... 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 f.fainelli@gmail.com
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.... 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 jforbes@fedoraproject.org
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.... 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 skhan@linuxfoundation.org
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 bagasdotme@gmail.com
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.... 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 jonathanh@nvidia.com
Jon
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.... 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...
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... https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.14... 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 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.... 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...
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 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.... 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...
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
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.... 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...
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 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...
-- Linaro LKFT https://lkft.linaro.org
On Fri, Mar 03, 2023 at 01:32:47AM +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.... 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...
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
On Fri, 3 Mar 2023 at 12:31, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Fri, Mar 03, 2023 at 01:32:47AM +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.... 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...
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
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.... 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...
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 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.... 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...
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 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.... > 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...
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 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:
…
....
…
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
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 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: > …
....
> …
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 gregkh@linuxfoundation.org:
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 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:
…
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 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 gregkh@linuxfoundation.org:
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 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: > …
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 pabeni@redhat.com 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 pabeni@redhat.com 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
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 sudip.mukherjee@codethink.co.uk
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.... 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 srw@sladewatkins.net
-- 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 rudi@heitbaum.com -- 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 linux@roeck-us.net
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.... 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 re@w6rz.net
-
Bagas Sanjaya -
Conor Dooley -
Florian Fainelli -
Greg Kroah-Hartman -
Guenter Roeck -
Jon Hunter -
Justin Forbes -
Matthieu Baerts -
Naresh Kamboju -
Paolo Abeni -
Ron Economos -
Rudi Heitbaum -
Shuah Khan -
Slade Watkins -
Sudip Mukherjee (Codethink)