5.15.158-rc1 review
Greg Kroah-Hartman
maintainercover 5.15.158-rc1 review
This is the start of the stable review cycle for the 5.15.158 release. There are 80 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 Thu, 02 May 2024 10:30:27 +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/v5.x/stable-review/patch-5.15.158-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-5.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.15.158-rc1
Randy Dunlap <[email protected]>
serial: core: fix kernel-doc for uart_port_unlock_irqrestore()
Yick Xie <[email protected]>
udp: preserve the connected status if only UDP cmsg
Matthew Wilcox (Oracle) <[email protected]>
bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS
Nam Cao <[email protected]>
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
Nam Cao <[email protected]>
fbdev: fix incorrect address computation in deferred IO
Wolfram Sang <[email protected]>
i2c: smbus: fix NULL function pointer dereference
Samuel Holland <[email protected]>
riscv: Fix TASK_SIZE on 64-bit NOMMU
Baoquan He <[email protected]>
riscv: fix VMALLOC_START definition
Fenghua Yu <[email protected]>
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
Sean Anderson <[email protected]>
dma: xilinx_dpdma: Fix locking
Andy Shevchenko <[email protected]>
idma64: Don't try to serve interrupts when device is powered off
Arnd Bergmann <[email protected]>
dmaengine: owl: fix register access functions
Eric Dumazet <[email protected]>
tcp: Fix NEW_SYN_RECV handling in inet_twsk_purge()
Kuniyuki Iwashima <[email protected]>
tcp: Clean up kernel listener's reqsk in inet_twsk_purge()
Arnd Bergmann <[email protected]>
mtd: diskonchip: work around ubsan link failure
Andrey Ryabinin <[email protected]>
stackdepot: respect __GFP_NOLOCKDEP allocation flag
Peter Münster <[email protected]>
net: b44: set pause params only when interface is up
Rahul Rameshbabu <[email protected]>
ethernet: Add helper for assigning packet type when dest address does not match device address
Guanrui Huang <[email protected]>
irqchip/gic-v3-its: Prevent double free on error
Mukul Joshi <[email protected]>
drm/amdgpu: Fix leak when GPU memory allocation fails
Alex Deucher <[email protected]>
drm/amdgpu/sdma5.2: use legacy HDP flush for SDMA2/3
Iskander Amara <[email protected]>
arm64: dts: rockchip: enable internal pull-up for Q7_THRM# on RK3399 Puma
Sean Christopherson <[email protected]>
cpu: Re-enable CPU mitigations by default for !X86 architectures
Johannes Thumshirn <[email protected]>
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
Mantas Pucka <[email protected]>
mmc: sdhci-msm: pervent access to suspended controller
Johan Hovold <[email protected]>
Bluetooth: qca: fix NULL-deref on non-serdev suspend
WangYuli <[email protected]>
Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x0bda:0x4853
Nathan Chancellor <[email protected]>
Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()
David Kaplan <[email protected]>
x86/cpu: Fix check for RDPKRU in __show_regs()
Robin H. Johnson <[email protected]>
tracing: Increase PERF_MAX_TRACE_SIZE to handle Sentinel1 and docker together
Robin H. Johnson <[email protected]>
tracing: Show size of requested perf buffer
Shifeng Li <[email protected]>
net/mlx5e: Fix a race in command alloc flow
Greg Kroah-Hartman <[email protected]>
Revert "crypto: api - Disallow identical driver names"
Zack Rusin <[email protected]>
drm/vmwgfx: Fix crtc's atomic check conditional
Jim Cromie <[email protected]>
drm-print: add drm_dbg_driver to improve namespace symmetry
Emil Kronborg <[email protected]>
serial: mxs-auart: add spinlock around changing cts state
Thomas Gleixner <[email protected]>
serial: core: Provide port lock wrappers
Kuniyuki Iwashima <[email protected]>
af_unix: Suppress false-positive lockdep splat for spin_lock() in __unix_gc().
Jason Reeder <[email protected]>
net: ethernet: ti: am65-cpts: Fix PTPv1 message type on TX packets
Sudheer Mogilappagari <[email protected]>
iavf: Fix TC config comparison with existing adapter TC config
Erwan Velu <[email protected]>
i40e: Report MFS in decimal base instead of hex
Sindhu Devale <[email protected]>
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables: honor table dormant flag from netdev release event path
Ido Schimmel <[email protected]>
mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work
Ido Schimmel <[email protected]>
mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
Ido Schimmel <[email protected]>
mlxsw: spectrum_acl_tcam: Fix warning during rehash
Ido Schimmel <[email protected]>
mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
Ido Schimmel <[email protected]>
mlxsw: spectrum_acl_tcam: Rate limit error message
Ido Schimmel <[email protected]>
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
Ido Schimmel <[email protected]>
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
Ido Schimmel <[email protected]>
mlxsw: spectrum_acl_tcam: Fix race during rehash delayed work
Hyunwoo Kim <[email protected]>
net: openvswitch: Fix Use-After-Free in ovs_ct_exit
Ismael Luceno <[email protected]>
ipvs: Fix checksumming on GSO of SCTP packets
Hyunwoo Kim <[email protected]>
net: gtp: Fix Use-After-Free in gtp_dellink
Eric Dumazet <[email protected]>
net: usb: ax88179_178a: stop lying about skb->truesize
Eric Dumazet <[email protected]>
ipv4: check for NULL idev in ip_route_use_hint()
Paul Geurts <[email protected]>
NFC: trf7970a: disable all regulators on removal
Hangbin Liu <[email protected]>
bridge/br_netlink.c: no need to return void function
Eric Dumazet <[email protected]>
icmp: prevent possible NULL dereferences from icmp_build_probe()
Ido Schimmel <[email protected]>
mlxsw: core: Unregister EMAD trap using FORWARD action
David Bauer <[email protected]>
vxlan: drop packets from invalid src-address
Miri Korenblit <[email protected]>
wifi: iwlwifi: mvm: return uid from iwl_mvm_build_scan_cmd
Avraham Stern <[email protected]>
wifi: iwlwifi: mvm: remove old PASN station when adding a new one
Alexey Brodkin <[email protected]>
ARC: [plat-hsdk]: Remove misplaced interrupt-cells property
Rafał Miłecki <[email protected]>
arm64: dts: mediatek: mt2712: fix validation errors
Rafał Miłecki <[email protected]>
arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block
Rafał Miłecki <[email protected]>
arm64: dts: mediatek: mt7622: fix ethernet controller "compatible"
Rafał Miłecki <[email protected]>
arm64: dts: mediatek: mt7622: fix IR nodename
Rafał Miłecki <[email protected]>
arm64: dts: mediatek: mt7622: fix clock controllers
Felix Fietkau <[email protected]>
arm64: dts: mediatek: mt7622: introduce nodes for Wireless Ethernet Dispatch
Felix Fietkau <[email protected]>
arm64: dts: mediatek: mt7622: add support for coherent DMA
Ikjoon Jang <[email protected]>
arm64: dts: mediatek: mt8183: Add power-domains properity to mfgcfg
Dragan Simic <[email protected]>
arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro dts
Quentin Schulz <[email protected]>
arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for RK3399 Puma
Iskander Amara <[email protected]>
arm64: dts: rockchip: fix alphabetical ordering RK3399 puma
Quentin Schulz <[email protected]>
arm64: dts: rockchip: enable internal pull-up on Q7_USB_ID for RK3399 Puma
Yaraslau Furman <[email protected]>
HID: logitech-dj: allow mice to use all types of reports
Zhang Lixu <[email protected]>
HID: intel-ish-hid: ipc: Fix dev_err usage with uninitialized dev->devc
Takayuki Nagata <[email protected]>
cifs: reinstate original behavior again for forceuid/forcegid
Paulo Alcantara <[email protected]>
smb: client: fix rename(2) regression against samba
-------------
Diffstat:
Makefile | 4 +- arch/Kconfig | 8 +++ arch/arc/boot/dts/hsdk.dts | 1 - arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 8 +-- arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 3 +- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 62 +++++++++++------ arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 + .../boot/dts/rockchip/rk3399-pinebook-pro.dts | 1 - arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 31 ++++++--- arch/riscv/include/asm/pgtable.h | 4 +- arch/x86/Kconfig | 11 +-- arch/x86/kernel/process_64.c | 2 +- crypto/algapi.c | 1 - drivers/bluetooth/btusb.c | 2 + drivers/bluetooth/hci_qca.c | 3 + drivers/dma/idma64.c | 4 ++ drivers/dma/idxd/perfmon.c | 9 +-- drivers/dma/owl-dma.c | 4 +- drivers/dma/xilinx/xilinx_dpdma.c | 13 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 + drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 24 ++++--- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 ++- drivers/hid/hid-logitech-dj.c | 4 +- drivers/hid/i2c-hid/i2c-hid-core.c | 8 --- drivers/hid/intel-ish-hid/ipc/ipc.c | 2 +- drivers/i2c/i2c-core-base.c | 12 ++-- drivers/irqchip/irq-gic-v3-its.c | 9 +-- drivers/mmc/host/sdhci-msm.c | 16 ++++- drivers/mtd/nand/raw/diskonchip.c | 4 +- drivers/net/ethernet/broadcom/b44.c | 14 ++-- drivers/net/ethernet/intel/i40e/i40e_main.c | 6 +- drivers/net/ethernet/intel/iavf/iavf_main.c | 30 +++++++- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 12 ++-- drivers/net/ethernet/mellanox/mlxsw/core.c | 2 +- .../ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 54 ++++++++++++--- drivers/net/ethernet/ti/am65-cpts.c | 5 ++ drivers/net/gtp.c | 3 +- drivers/net/usb/ax88179_178a.c | 11 +-- drivers/net/vxlan/vxlan_core.c | 4 ++ .../net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 2 + drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 3 +- drivers/nfc/trf7970a.c | 42 ++++++------ drivers/tty/serial/mxs-auart.c | 8 ++- drivers/video/fbdev/core/fb_defio.c | 2 +- fs/btrfs/backref.c | 12 +--- fs/cifs/cifsfs.c | 1 + fs/cifs/fs_context.c | 12 ++++ fs/cifs/fs_context.h | 2 + include/drm/drm_print.h | 3 +- include/linux/etherdevice.h | 25 +++++++ include/linux/serial_core.h | 79 ++++++++++++++++++++++ include/linux/trace_events.h | 2 +- include/net/af_unix.h | 3 + kernel/bounds.c | 2 +- kernel/cpu.c | 4 +- kernel/trace/trace_event_perf.c | 3 +- lib/stackdepot.c | 4 +- net/bluetooth/l2cap_sock.c | 7 +- net/bluetooth/sco.c | 7 +- net/bridge/br_netlink.c | 2 +- net/ethernet/eth.c | 12 +--- net/ipv4/icmp.c | 12 +++- net/ipv4/inet_timewait_sock.c | 34 ++++++---- net/ipv4/route.c | 3 + net/ipv4/udp.c | 5 +- net/ipv6/udp.c | 5 +- net/netfilter/ipvs/ip_vs_proto_sctp.c | 6 +- net/netfilter/nft_chain_filter.c | 4 +- net/openvswitch/conntrack.c | 4 +- net/unix/garbage.c | 2 +- 70 files changed, 503 insertions(+), 213 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/80 smb: client: fix rename(2) regression against samba
5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paulo Alcantara <[email protected]>
[ Upstream commit 18d86965e31f9be4d477da0744a7cdc9815858de ]
After commit 2c7d399e551c ("smb: client: reuse file lease key in compound operations") the client started reusing lease keys for rename, unlink and set path size operations to prevent it from breaking its own leases and thus causing unnecessary lease breaks to same connection.
The implementation relies on positive dentries and cifsInodeInfo::lease_granted to decide whether reusing lease keys for the compound requests. cifsInodeInfo::lease_granted was introduced by commit 0ab95c2510b6 ("Defer close only when lease is enabled.") to indicate whether lease caching is granted for a specific file, but that can only happen until file is open, so cifsInodeInfo::lease_granted was left uninitialised in ->alloc_inode and then client started sending random lease keys for files that hadn't any leases.
This fixes the following test case against samba:
mount.cifs //srv/share /mnt/1 -o ...,nosharesock
mount.cifs //srv/share /mnt/2 -o ...,nosharesock
touch /mnt/1/foo; tail -f /mnt/1/foo & pid=$!
mv /mnt/2/foo /mnt/2/bar # fails with -EIO
kill $pid
--- fs/cifs/cifsfs.c | 1 + 1 file changed, 1 insertion(+)
fs/cifs/cifsfs.c +1 -0
@@ -374,6 +374,7 @@ cifs_alloc_inode(struct super_block *sb)* server, can not assume caching of file data or metadata. */ cifs_set_oplock_level (cifs_inode,0 ); + cifs_inode->lease_granted = false; cifs_inode->flags =0 ;spin_lock_init (&cifs_inode->writers_lock); cifs_inode->writers =0 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 2/80 cifs: reinstate original behavior again for forceuid/forcegid
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takayuki Nagata <[email protected]>
[ Upstream commit 77d8aa79ecfb209308e0644c02f655122b31def7 ]
forceuid/forcegid should be enabled by default when uid=/gid= options are specified, but commit 24e0a1eff9e2 ("cifs: switch to new mount api") changed the behavior. Due to the change, a mounted share does not show intentional uid/gid for files and directories even though uid=/gid= options are specified since forceuid/forcegid are not enabled.
This patch reinstates original behavior that overrides uid/gid with specified uid/gid by the options.
--- fs/cifs/fs_context.c | 12 ++++++++++++ fs/cifs/fs_context.h | 2 ++ 2 files changed, 14 insertions(+)
fs/cifs/fs_context.c +12 -0
@@ -672,6 +672,16 @@ static int smb3_fs_context_validate(struct fs_context *fc)/* set the port that we got earlier */ cifs_set_port ((struct sockaddr *)&ctx->dstaddr, ctx->port); +if (ctx->uid_specified && !ctx->forceuid_specified) { + ctx->override_uid =1 ; +pr_notice ("enabling forceuid mount option implicitly because uid= option is specified\n" ); + } + +if (ctx->gid_specified && !ctx->forcegid_specified) { + ctx->override_gid =1 ; +pr_notice ("enabling forcegid mount option implicitly because gid= option is specified\n" ); + } +if (ctx->override_uid && !ctx->uid_specified) { ctx->override_uid =0 ;pr_notice ("ignoring forceuid mount option specified with no uid= option\n" );
@@ -903,12 +913,14 @@ static int smb3_fs_context_parse_param(struct fs_context *fc, ctx->override_uid =0 ; else ctx->override_uid = 1; + ctx->forceuid_specified = true;break ;case Opt_forcegid:if (result.negated) ctx->override_gid =0 ;else ctx->override_gid =1 ; + ctx->forcegid_specified = true;break ;case Opt_perm:if (result.negated)
fs/cifs/fs_context.h +2 -0
@@ -152,6 +152,8 @@ enum cifs_param { };struct smb3_fs_context { +bool forceuid_specified; +bool forcegid_specified;bool uid_specified;bool cruid_specified;bool gid_specified;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 3/80 HID: intel-ish-hid: ipc: Fix dev_err usage with uninitialized dev->devc
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Lixu <[email protected]>
[ Upstream commit 92826905ae340b7f2b25759a06c8c60bfc476b9f ]
The variable dev->devc in ish_dev_init was utilized by dev_err before it was properly assigned. To rectify this, the assignment of dev->devc has been moved to immediately follow memory allocation.
Without this change "(NULL device *)" is printed for device information.
--- drivers/hid/intel-ish-hid/ipc/ipc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hid/intel-ish-hid/ipc/ipc.c +1 -1
@@ -944,6 +944,7 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev)if (!dev)return NULL ; + dev->devc = &pdev->dev;ishtp_device_init (dev);init_waitqueue_head (&dev->wait_hw_ready);
@@ -979,7 +980,6 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev) } dev->ops = &ish_hw_ops; - dev->devc = &pdev->dev; dev->mtu =IPC_PAYLOAD_SIZE -sizeof (struct ishtp_msg_hdr );return dev; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 4/80 HID: logitech-dj: allow mice to use all types of reports
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yaraslau Furman <[email protected]>
[ Upstream commit 21f28a7eb78dea6c59be6b0a5e0b47bf3d25fcbb ]
You can bind whatever action you want to the mouse's reprogrammable buttons using Windows application. Allow Linux to receive multimedia keycodes.
--- drivers/hid/hid-logitech-dj.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/hid/hid-logitech-dj.c +1 -3
@@ -965,9 +965,7 @@ static void logi_hidpp_dev_conn_notif_equad(struct hid_device *hdev, }break ;case REPORT_TYPE_MOUSE : - workitem->reports_supported |=STD_MOUSE |HIDPP ; -if (djrcv_dev->type == recvr_type_mouse_only) - workitem->reports_supported |=MULTIMEDIA ; + workitem->reports_supported |=STD_MOUSE |HIDPP |MULTIMEDIA ;break ; } }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 5/80 arm64: dts: rockchip: enable internal pull-up on Q7_USB_ID for RK3399 Puma
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Quentin Schulz <[email protected]>
[ Upstream commit e6b1168f37e3f86d9966276c5a3fff9eb0df3e5f ]
The Q7_USB_ID has a diode used as a level-shifter, and is used as an input pin. The SoC default for this pin is a pull-up, which is correct but the pinconf in the introducing commit missed that, so let's fix this oversight.
--- arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +1 -1
@@ -432,7 +432,7 @@ usb3 { usb3_id: usb3-id { rockchip,pins = - <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>; + <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_up>; }; }; };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 6/80 arm64: dts: rockchip: fix alphabetical ordering RK3399 puma
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Iskander Amara <[email protected]>
[ Upstream commit f0abb4b2c7acf3c3e4130dc3f54cd90cf2ae62bc ]
Nodes overridden by their reference should be ordered alphabetically to make it easier to read the DTS. pinctrl node is defined in the wrong location so let's reorder it.
Stable-dep-of: 945a7c857091 ("arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for RK3399 Puma")
--- arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +9 -9
@@ -390,15 +390,6 @@ gpio1830-supply = <&vcc_1v8>; }; -&pmu_io_domains { - status = "okay"; - pmu1830-supply = <&vcc_1v8>; -}; - -&pwm2 { - status = "okay"; -}; - &pinctrl { i2c8 { i2c8_xfer_a: i2c8-xfer {
@@ -437,6 +428,15 @@ }; }; +&pmu_io_domains { + status = "okay"; + pmu1830-supply = <&vcc_1v8>; +}; + +&pwm2 { + status = "okay"; +}; + &sdhci { /* * Signal integrity isn't great at 200MHz but 100MHz has proven stable
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 7/80 arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for RK3399 Puma
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Quentin Schulz <[email protected]>
[ Upstream commit 945a7c8570916650a415757d15d83e0fa856a686 ]
The PCIE_WAKE# has a diode used as a level-shifter, and is used as an input pin. While the SoC default is to enable the pull-up, the core rk3399 pinconf for this pin opted for pull-none. So as to not disturb the behaviour of other boards which may rely on pull-none instead of pull-up, set the needed pull-up only for RK3399 Puma.
--- arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +5 -0
@@ -390,6 +390,11 @@ gpio1830-supply = <&vcc_1v8>; }; +&pcie_clkreqn_cpm { + rockchip,pins = + <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_up>; +}; + &pinctrl { i2c8 { i2c8_xfer_a: i2c8-xfer {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 8/80 arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro dts
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dragan Simic <[email protected]>
[ Upstream commit 43853e843aa6c3d47ff2b0cce898318839483d05 ]
Remove a redundant node from the Pine64 Pinebook Pro dts, which is intended to provide a value for the delay in PCI Express enumeration, but that isn't supported without additional out-of-tree kernel patches.
There were already efforts to upstream those kernel patches, because they reportedly make some PCI Express cards (such as LSI SAS HBAs) usable in Pine64 RockPro64 (which is also based on the RK3399); otherwise, those PCI Express cards fail to enumerate. However, providing the required background and explanations proved to be a tough nut to crack, which is the reason why those patches remain outside of the kernel mainline for now.
If those out-of-tree patches eventually become upstreamed, the resulting device-tree changes will almost surely belong to the RK3399 SoC dtsi. Also, the above-mentioned unusable-without-out-of-tree-patches PCI Express devices are in all fairness not usable in a Pinebook Pro without some extensive hardware modifications, which is another reason to delete this redundant node. When it comes to the Pinebook Pro, only M.2 NVMe SSDs can be installed out of the box (using an additional passive adapter PCB sold separately by Pine64), which reportedly works fine with no additional patches.
--- arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 1 - 1 file changed, 1 deletion(-)
arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts +0 -1
@@ -790,7 +790,6 @@ }; &pcie0 { - bus-scan-delay-ms = <1000>; ep-gpios = <&gpio2 RK_PD4 GPIO_ACTIVE_HIGH>; num-lanes = <4>; pinctrl-names = "default";
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 9/80 arm64: dts: mediatek: mt8183: Add power-domains properity to mfgcfg
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ikjoon Jang <[email protected]>
[ Upstream commit 1781f2c461804c0123f59afc7350e520a88edffb ]
mfgcfg clock is under MFG_ASYNC power domain.
--- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 + 1 file changed, 1 insertion(+)
arch/arm64/boot/dts/mediatek/mt8183.dtsi +1 -0
@@ -1088,6 +1088,7 @@ compatible = "mediatek,mt8183-mfgcfg", "syscon"; reg = <0 0x13000000 0 0x1000>; #clock-cells = <1>; + power-domains = <&spm MT8183_POWER_DOMAIN_MFG_ASYNC>; }; gpu: gpu@13040000 {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 10/80 arm64: dts: mediatek: mt7622: add support for coherent DMA
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
[ Upstream commit 3abd063019b6a01762f9fccc39505f29d029360a ]
It improves performance by eliminating the need for a cache flush on rx and tx
Stable-dep-of: 3ba5a6159434 ("arm64: dts: mediatek: mt7622: fix clock controllers")
--- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arm64/boot/dts/mediatek/mt7622.dtsi +3 -1
@@ -357,7 +357,7 @@ }; cci_control2: slave-if@5000 { - compatible = "arm,cci-400-ctrl-if"; + compatible = "arm,cci-400-ctrl-if", "syscon"; interface-type = "ace"; reg = <0x5000 0x1000>; };
@@ -938,6 +938,8 @@ power-domains = <&scpsys MT7622_POWER_DOMAIN_ETHSYS>; mediatek,ethsys = <ðsys>; mediatek,sgmiisys = <&sgmiisys>; + mediatek,cci-control = <&cci_control2>; + dma-coherent; #address-cells = <1>; #size-cells = <0>; status = "disabled";
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 11/80 arm64: dts: mediatek: mt7622: introduce nodes for Wireless Ethernet Dispatch
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
[ Upstream commit e9b65ecb7c3050dd34ee22ce17f1cf95e8405b15 ]
Introduce wed0 and wed1 nodes in order to enable offloading forwarding between ethernet and wireless devices on the mt7622 chipset.
Stable-dep-of: 3ba5a6159434 ("arm64: dts: mediatek: mt7622: fix clock controllers")
--- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 28 ++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
arch/arm64/boot/dts/mediatek/mt7622.dtsi +28 -0
@@ -894,6 +894,11 @@ }; }; + hifsys: syscon@1af00000 { + compatible = "mediatek,mt7622-hifsys", "syscon"; + reg = <0 0x1af00000 0 0x70>; + }; + ethsys: syscon@1b000000 { compatible = "mediatek,mt7622-ethsys", "syscon";
@@ -912,6 +917,26 @@ #dma-cells = <1>; }; + pcie_mirror: pcie-mirror@10000400 { + compatible = "mediatek,mt7622-pcie-mirror", + "syscon"; + reg = <0 0x10000400 0 0x10>; + }; + + wed0: wed@1020a000 { + compatible = "mediatek,mt7622-wed", + "syscon"; + reg = <0 0x1020a000 0 0x1000>; + interrupts = <GIC_SPI 214 IRQ_TYPE_LEVEL_LOW>; + }; + + wed1: wed@1020b000 { + compatible = "mediatek,mt7622-wed", + "syscon"; + reg = <0 0x1020b000 0 0x1000>; + interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_LOW>; + }; + eth: ethernet@1b100000 { compatible = "mediatek,mt7622-eth", "mediatek,mt2701-eth",
@@ -939,6 +964,9 @@ mediatek,ethsys = <ðsys>; mediatek,sgmiisys = <&sgmiisys>; mediatek,cci-control = <&cci_control2>; + mediatek,wed = <&wed0>, <&wed1>; + mediatek,pcie-mirror = <&pcie_mirror>; + mediatek,hifsys = <&hifsys>; dma-coherent; #address-cells = <1>; #size-cells = <0>;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 12/80 arm64: dts: mediatek: mt7622: fix clock controllers
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafał Miłecki <[email protected]>
[ Upstream commit 3ba5a61594347ab46e7c2cff6cd63ea0f1282efb ]
1. Drop unneeded "syscon"s (bindings were updated recently)
2. Use "clock-controller" in nodenames
3. Add missing "#clock-cells"
--- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 27 +++++++++++------------- 1 file changed, 12 insertions(+), 15 deletions(-)
arch/arm64/boot/dts/mediatek/mt7622.dtsi +12 -15
@@ -275,16 +275,14 @@ }; }; - apmixedsys: apmixedsys@10209000 { - compatible = "mediatek,mt7622-apmixedsys", - "syscon"; + apmixedsys: clock-controller@10209000 { + compatible = "mediatek,mt7622-apmixedsys"; reg = <0 0x10209000 0 0x1000>; #clock-cells = <1>; }; - topckgen: topckgen@10210000 { - compatible = "mediatek,mt7622-topckgen", - "syscon"; + topckgen: clock-controller@10210000 { + compatible = "mediatek,mt7622-topckgen"; reg = <0 0x10210000 0 0x1000>; #clock-cells = <1>; };
@@ -715,9 +713,8 @@ power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>; }; - ssusbsys: ssusbsys@1a000000 { - compatible = "mediatek,mt7622-ssusbsys", - "syscon"; + ssusbsys: clock-controller@1a000000 { + compatible = "mediatek,mt7622-ssusbsys"; reg = <0 0x1a000000 0 0x1000>; #clock-cells = <1>; #reset-cells = <1>;
@@ -774,9 +771,8 @@ }; }; - pciesys: pciesys@1a100800 { - compatible = "mediatek,mt7622-pciesys", - "syscon"; + pciesys: clock-controller@1a100800 { + compatible = "mediatek,mt7622-pciesys"; reg = <0 0x1a100800 0 0x1000>; #clock-cells = <1>; #reset-cells = <1>;
@@ -894,12 +890,13 @@ }; }; - hifsys: syscon@1af00000 { - compatible = "mediatek,mt7622-hifsys", "syscon"; + hifsys: clock-controller@1af00000 { + compatible = "mediatek,mt7622-hifsys"; reg = <0 0x1af00000 0 0x70>; + #clock-cells = <1>; }; - ethsys: syscon@1b000000 { + ethsys: clock-controller@1b000000 { compatible = "mediatek,mt7622-ethsys", "syscon"; reg = <0 0x1b000000 0 0x1000>;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 13/80 arm64: dts: mediatek: mt7622: fix IR nodename
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafał Miłecki <[email protected]>
[ Upstream commit 800dc93c3941e372c94278bf4059e6e82f60bd66 ]
Fix following validation error:arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: cir@10009000: $nodename:0: 'cir@10009000' does not match '^ir(-receiver)?(@[a-f0-9]+)?$'
from schema $id: http://devicetree.org/schemas/media/mediatek,mt7622-cir.yaml#
--- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/mediatek/mt7622.dtsi +1 -1
@@ -244,7 +244,7 @@ clock-names = "hif_sel"; }; - cir: cir@10009000 { + cir: ir-receiver@10009000 { compatible = "mediatek,mt7622-cir"; reg = <0 0x10009000 0 0x1000>; interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_LOW>;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 14/80 arm64: dts: mediatek: mt7622: fix ethernet controller "compatible"
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafał Miłecki <[email protected]>
[ Upstream commit 208add29ce5b7291f6c466e4dfd9cbf61c72888e ]
Fix following validation error:arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: ethernet@1b100000: compatible: ['mediatek,mt7622-eth', 'mediatek,mt2701-eth', 'syscon'] is too long
from schema $id: http://devicetree.org/schemas/net/mediatek,net.yaml#
(and other complains about wrong clocks).
--- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
arch/arm64/boot/dts/mediatek/mt7622.dtsi +1 -3
@@ -935,9 +935,7 @@ }; eth: ethernet@1b100000 { - compatible = "mediatek,mt7622-eth", - "mediatek,mt2701-eth", - "syscon"; + compatible = "mediatek,mt7622-eth"; reg = <0 0x1b100000 0 0x20000>; interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_LOW>, <GIC_SPI 224 IRQ_TYPE_LEVEL_LOW>,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 15/80 arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafał Miłecki <[email protected]>
[ Upstream commit ecb5b0034f5bcc35003b4b965cf50c6e98316e79 ]
Binding doesn't specify "reset-names" property and Linux driver also doesn't use it.
Fix following validation error:arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: thermal@1100b000: Unevaluated properties are not allowed ('reset-names' was unexpected)
from schema $id: http://devicetree.org/schemas/thermal/mediatek,thermal.yaml#
--- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 - 1 file changed, 1 deletion(-)
arch/arm64/boot/dts/mediatek/mt7622.dtsi +0 -1
@@ -505,7 +505,6 @@ <&pericfg CLK_PERI_AUXADC_PD>; clock-names = "therm", "auxadc"; resets = <&pericfg MT7622_PERI_THERM_SW_RST>; - reset-names = "therm"; mediatek,auxadc = <&auxadc>; mediatek,apmixedsys = <&apmixedsys>; nvmem-cells = <&thermal_calibration>;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 16/80 arm64: dts: mediatek: mt2712: fix validation errors
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafał Miłecki <[email protected]>
[ Upstream commit 3baac7291effb501c4d52df7019ebf52011e5772 ]
1. Fixup infracfg clock controller binding
It also acts as reset controller so #reset-cells is required.
2. Use -pins suffix for pinctrl
This fixes:arch/arm64/boot/dts/mediatek/mt2712-evb.dtb: syscon@10001000: '#reset-cells' is a required property
from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#arch/arm64/boot/dts/mediatek/mt2712-evb.dtb: pinctrl@1000b000: 'eth_default', 'eth_sleep', 'usb0_iddig', 'usb1_iddig' do not match any of the regexes: 'pinctrl-[0-9]+', 'pins$'
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt65xx-pinctrl.yaml#
--- arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 8 ++++---- arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 3 ++- 2 files changed, 6 insertions(+), 5 deletions(-)
arch/arm64/boot/dts/mediatek/mt2712-evb.dts +4 -4
@@ -127,7 +127,7 @@ }; &pio { - eth_default: eth_default { + eth_default: eth-default-pins { tx_pins { pinmux = <MT2712_PIN_71_GBE_TXD3__FUNC_GBE_TXD3>, <MT2712_PIN_72_GBE_TXD2__FUNC_GBE_TXD2>,
@@ -154,7 +154,7 @@ }; }; - eth_sleep: eth_sleep { + eth_sleep: eth-sleep-pins { tx_pins { pinmux = <MT2712_PIN_71_GBE_TXD3__FUNC_GPIO71>, <MT2712_PIN_72_GBE_TXD2__FUNC_GPIO72>,
@@ -180,14 +180,14 @@ }; }; - usb0_id_pins_float: usb0_iddig { + usb0_id_pins_float: usb0-iddig-pins { pins_iddig { pinmux = <MT2712_PIN_12_IDDIG_P0__FUNC_IDDIG_A>; bias-pull-up; }; }; - usb1_id_pins_float: usb1_iddig { + usb1_id_pins_float: usb1-iddig-pins { pins_iddig { pinmux = <MT2712_PIN_14_IDDIG_P1__FUNC_IDDIG_B>; bias-pull-up;
arch/arm64/boot/dts/mediatek/mt2712e.dtsi +2 -1
@@ -249,10 +249,11 @@ #clock-cells = <1>; }; - infracfg: syscon@10001000 { + infracfg: clock-controller@10001000 { compatible = "mediatek,mt2712-infracfg", "syscon"; reg = <0 0x10001000 0 0x1000>; #clock-cells = <1>; + #reset-cells = <1>; }; pericfg: syscon@10003000 {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 17/80 ARC: [plat-hsdk]: Remove misplaced interrupt-cells property
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Brodkin <[email protected]>
[ Upstream commit 61231eb8113ce47991f35024f9c20810b37996bf ]
"gmac" node stands for just an ordinary Ethernet controller, which is by no means a provider of interrupts, i.e. it doesn't serve as an interrupt controller, thus "#interrupt-cells" property doesn't belong to it and so we remove it.
Fixes:
------------>8------------
DTC arch/arc/boot/dts/hsdk.dtb
arch/arc/boot/dts/hsdk.dts:207.23-235.5: Warning (interrupt_provider): /soc/ethernet@8000: '#interrupt-cells' found, but node is not an interrupt provider arch/arc/boot/dts/hsdk.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
------------>8------------
--- arch/arc/boot/dts/hsdk.dts | 1 - 1 file changed, 1 deletion(-)
arch/arc/boot/dts/hsdk.dts +0 -1
@@ -205,7 +205,6 @@ }; gmac: ethernet@8000 { - #interrupt-cells = <1>; compatible = "snps,dwmac"; reg = <0x8000 0x2000>; interrupts = <10>;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 18/80 wifi: iwlwifi: mvm: remove old PASN station when adding a new one
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avraham Stern <[email protected]>
[ Upstream commit dbfff5bf9292714f02ace002fea8ce6599ea1145 ]
If a PASN station is added, and an old PASN station already exists for the same mac address, remove the old station before adding the new one. Keeping the old station caueses old security context to be used in measurements.
--- drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c +2 -0
@@ -48,6 +48,8 @@ int iwl_mvm_ftm_add_pasn_sta(struct iwl_mvm *mvm, struct ieee80211_vif *vif,if (!pasn)return -ENOBUFS ; +iwl_mvm_ftm_remove_pasn_sta (mvm, addr); + pasn->cipher =iwl_mvm_cipher_to_location_cipher (cipher);switch (pasn->cipher) {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 19/80 wifi: iwlwifi: mvm: return uid from iwl_mvm_build_scan_cmd
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miri Korenblit <[email protected]>
[ Upstream commit bada85a3f584763deadd201147778c3e791d279c ]
This function is supposed to return a uid on success, and an errno in failure.
But it currently returns the return value of the specific cmd version handler, which in turn returns 0 on success and errno otherwise. This means that on success, iwl_mvm_build_scan_cmd will return 0 regardless if the actual uid.
Fix this by returning the uid if the handler succeeded.
--- drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/intel/iwlwifi/mvm/scan.c +2 -1
@@ -2571,7 +2571,8 @@ static int iwl_mvm_build_scan_cmd(struct iwl_mvm *mvm,if (ver_handler->version != scan_ver)continue ; -return ver_handler->handler (mvm, vif, params, type, uid); + err = ver_handler->handler (mvm, vif, params, type, uid); +return err ? : uid; } err =iwl_mvm_scan_umac (mvm, vif, params, type, uid);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 20/80 vxlan: drop packets from invalid src-address
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Bauer <[email protected]>
[ Upstream commit f58f45c1e5b92975e91754f5407250085a6ae7cf ]
The VXLAN driver currently does not check if the inner layer2 source-address is valid.
In case source-address snooping/learning is enabled, a entry in the FDB for the invalid address is created with the layer3 address of the tunnel endpoint.
If the frame happens to have a non-unicast address set, all this non-unicast traffic is subsequently not flooded to the tunnel network but sent to the learnt host in the FDB. To make matters worse, this FDB entry does not expire.
Apply the same filtering for packets as it is done for bridges. This not only drops these invalid packets but avoids them from being learnt into the FDB.
--- drivers/net/vxlan/vxlan_core.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/vxlan/vxlan_core.c +4 -0
@@ -1779,6 +1779,10 @@ static bool vxlan_set_mac(struct vxlan_dev *vxlan,if (ether_addr_equal (eth_hdr (skb)->h_source, vxlan->dev->dev_addr))return false; +/* Ignore packets from invalid src-address */ +if (!is_valid_ether_addr (eth_hdr (skb)->h_source)) +return false; +/* Get address from the outer IP header */ if (vxlan_get_sk_family (vs) ==AF_INET ) { saddr.sin.sin_addr.s_addr =ip_hdr (skb)->saddr;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 21/80 mlxsw: core: Unregister EMAD trap using FORWARD action
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit 976c44af48141cd8595601c0af2a19a43c5b228b ]
The device's manual (PRM - Programmer's Reference Manual) classifies the trap that is used to deliver EMAD responses as an "event trap". Among other things, it means that the only actions that can be associated with the trap are TRAP and FORWARD (NOP).
Currently, during driver de-initialization the driver unregisters the trap by setting its action to DISCARD, which violates the above guideline. Future firmware versions will prevent such misuses by returning an error. This does not prevent the driver from working, but an error will be printed to the kernel log during module removal / devlink reload:
mlxsw_spectrum 0000:03:00.0: Reg cmd access status failed (status=7(bad parameter)) mlxsw_spectrum 0000:03:00.0: Reg cmd access failed (reg_id=7003(hpkt),type=write)
Suppress the error message by aligning the driver to the manual and use a FORWARD (NOP) action when unregistering the trap.
--- drivers/net/ethernet/mellanox/mlxsw/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlxsw/core.c +1 -1
@@ -746,7 +746,7 @@ static void mlxsw_emad_rx_listener_func(struct sk_buff *skb, u8 local_port,static const struct mlxsw_listener mlxsw_emad_rx_listener =MLXSW_RXL (mlxsw_emad_rx_listener_func,ETHEMAD ,TRAP_TO_CPU , false, -EMAD ,DISCARD ); +EMAD ,FORWARD );static int mlxsw_emad_init (struct mlxsw_core *mlxsw_core) {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 22/80 icmp: prevent possible NULL dereferences from icmp_build_probe()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit c58e88d49097bd12dfcfef4f075b43f5d5830941 ]
First problem is a double call to __in_dev_get_rcu(), because the second one could return NULL.
if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list)
Second problem is a read from dev->ip6_ptr with no NULL check:
if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list))
Use the correct RCU API to fix these.
v2: add missing include <net/addrconf.h>
--- net/ipv4/icmp.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
net/ipv4/icmp.c +10 -2
@@ -92,6 +92,7 @@#include <net/inet_common.h> #include <net/ip_fib.h> #include <net/l3mdev.h> +#include <net/addrconf.h> /* * Build xmit assembly blocks
@@ -1035,6 +1036,8 @@ bool icmp_build_probe(struct sk_buff *skb, struct icmphdr *icmphdr)struct icmp_ext_hdr *ext_hdr, _ext_hdr;struct icmp_ext_echo_iio *iio, _iio;struct net *net =dev_net (skb->dev); +struct inet6_dev *in6_dev; +struct in_device *in_dev;struct net_device *dev;char buff[IFNAMSIZ ];u16 ident_len;
@@ -1118,10 +1121,15 @@ bool icmp_build_probe(struct sk_buff *skb, struct icmphdr *icmphdr)/* Fill bits in reply message */ if (dev->flags &IFF_UP ) status |=ICMP_EXT_ECHOREPLY_ACTIVE ; -if (__in_dev_get_rcu (dev) &&__in_dev_get_rcu (dev)->ifa_list) + + in_dev =__in_dev_get_rcu (dev); +if (in_dev &&rcu_access_pointer (in_dev->ifa_list)) status |=ICMP_EXT_ECHOREPLY_IPV4 ; -if (!list_empty (&rcu_dereference (dev->ip6_ptr)->addr_list)) + + in6_dev =__in6_dev_get (dev); +if (in6_dev && !list_empty (&in6_dev->addr_list)) status |=ICMP_EXT_ECHOREPLY_IPV6 ; +dev_put (dev); icmphdr->un.echo.sequence |=htons (status);return true;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 23/80 bridge/br_netlink.c: no need to return void function
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hangbin Liu <[email protected]>
[ Upstream commit 4fd1edcdf13c0d234543ecf502092be65c5177db ]
br_info_notify is a void function. There is no need to return.
--- net/bridge/br_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/bridge/br_netlink.c +1 -1
@@ -619,7 +619,7 @@ void br_ifinfo_notify(int event, const struct net_bridge *br, {u32 filter =RTEXT_FILTER_BRVLAN_COMPRESSED ; -return br_info_notify (event, br, port, filter); +br_info_notify (event, br, port, filter); }/*
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 24/80 NFC: trf7970a: disable all regulators on removal
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Geurts <[email protected]>
[ Upstream commit 6bea4f03c6a4e973ef369e15aac88f37981db49e ]
During module probe, regulator 'vin' and 'vdd-io' are used and enabled, but the vdd-io regulator overwrites the 'vin' regulator pointer. During remove, only the vdd-io is disabled, as the vin regulator pointer is not available anymore. When regulator_put() is called during resource cleanup a kernel warning is given, as the regulator is still enabled.
Store the two regulators in separate pointers and disable both the regulators on module remove.
--- drivers/nfc/trf7970a.c | 42 +++++++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 19 deletions(-)
drivers/nfc/trf7970a.c +23 -19
@@ -424,7 +424,8 @@ struct trf7970a {enum trf7970a_state state;struct device *dev;struct spi_device *spi; -struct regulator *regulator; +struct regulator *vin_regulator; +struct regulator *vddio_regulator;struct nfc_digital_dev *ddev;u32 quirks;bool is_initiator;
@@ -1883,7 +1884,7 @@ static int trf7970a_power_up(struct trf7970a *trf)if (trf->state !=TRF7970A_ST_PWR_OFF )return 0 ; - ret =regulator_enable (trf->regulator); + ret =regulator_enable (trf->vin_regulator);if (ret) {dev_err (trf->dev,"%s - Can't enable VIN: %d\n" , __func__, ret);return ret;
@@ -1926,7 +1927,7 @@ static int trf7970a_power_down(struct trf7970a *trf)if (trf->en2_gpiod && !(trf->quirks &TRF7970A_QUIRK_EN2_MUST_STAY_LOW ))gpiod_set_value_cansleep (trf->en2_gpiod,0 ); - ret =regulator_disable (trf->regulator); + ret =regulator_disable (trf->vin_regulator);if (ret)dev_err (trf->dev,"%s - Can't disable VIN: %d\n" , __func__, ret);
@@ -2065,37 +2066,37 @@ static int trf7970a_probe(struct spi_device *spi)mutex_init (&trf->lock);INIT_DELAYED_WORK (&trf->timeout_work, trf7970a_timeout_work_handler); - trf->regulator =devm_regulator_get (&spi->dev,"vin" ); -if (IS_ERR (trf->regulator)) { - ret =PTR_ERR (trf->regulator); + trf->vin_regulator =devm_regulator_get (&spi->dev,"vin" ); +if (IS_ERR (trf->vin_regulator)) { + ret =PTR_ERR (trf->vin_regulator);dev_err (trf->dev,"Can't get VIN regulator: %d\n" , ret); goto err_destroy_lock; } - ret =regulator_enable (trf->regulator); + ret =regulator_enable (trf->vin_regulator);if (ret) {dev_err (trf->dev,"Can't enable VIN: %d\n" , ret); goto err_destroy_lock; } - uvolts =regulator_get_voltage (trf->regulator); + uvolts =regulator_get_voltage (trf->vin_regulator);if (uvolts >4000000 ) trf->chip_status_ctrl =TRF7970A_CHIP_STATUS_VRS5_3 ; - trf->regulator =devm_regulator_get (&spi->dev,"vdd-io" ); -if (IS_ERR (trf->regulator)) { - ret =PTR_ERR (trf->regulator); + trf->vddio_regulator =devm_regulator_get (&spi->dev,"vdd-io" ); +if (IS_ERR (trf->vddio_regulator)) { + ret =PTR_ERR (trf->vddio_regulator);dev_err (trf->dev,"Can't get VDD_IO regulator: %d\n" , ret); - goto err_destroy_lock; + goto err_disable_vin_regulator; } - ret =regulator_enable (trf->regulator); + ret =regulator_enable (trf->vddio_regulator);if (ret) {dev_err (trf->dev,"Can't enable VDD_IO: %d\n" , ret); - goto err_destroy_lock; + goto err_disable_vin_regulator; } -if (regulator_get_voltage (trf->regulator) ==1800000 ) { +if (regulator_get_voltage (trf->vddio_regulator) ==1800000 ) { trf->io_ctrl =TRF7970A_REG_IO_CTRL_IO_LOW ;dev_dbg (trf->dev,"trf7970a config vdd_io to 1.8V\n" ); }
@@ -2108,7 +2109,7 @@ static int trf7970a_probe(struct spi_device *spi)if (!trf->ddev) {dev_err (trf->dev,"Can't allocate NFC digital device\n" ); ret = -ENOMEM ; - goto err_disable_regulator; + goto err_disable_vddio_regulator; }nfc_digital_set_parent_dev (trf->ddev, trf->dev);
@@ -2137,8 +2138,10 @@ static int trf7970a_probe(struct spi_device *spi)trf7970a_shutdown (trf); err_free_ddev:nfc_digital_free_device (trf->ddev); -err_disable_regulator: -regulator_disable (trf->regulator); +err_disable_vddio_regulator: +regulator_disable (trf->vddio_regulator); +err_disable_vin_regulator: +regulator_disable (trf->vin_regulator); err_destroy_lock:mutex_destroy (&trf->lock);return ret;
@@ -2157,7 +2160,8 @@ static int trf7970a_remove(struct spi_device *spi)nfc_digital_unregister_device (trf->ddev);nfc_digital_free_device (trf->ddev); -regulator_disable (trf->regulator); +regulator_disable (trf->vddio_regulator); +regulator_disable (trf->vin_regulator);mutex_destroy (&trf->lock);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 25/80 ipv4: check for NULL idev in ip_route_use_hint()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1 ]
syzbot was able to trigger a NULL deref in fib_validate_source() in an old tree [1].
It appears the bug exists in latest trees.
All calls to __in_dev_get_rcu() must be checked for a NULL result.
[1]
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425 Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0 RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231 ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327 ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline] ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638 ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673 __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline] __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620 __netif_receive_skb_list net/core/dev.c:5672 [inline] netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764 netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816 xdp_recv_frames net/bpf/test_run.c:257 [inline] xdp_test_run_batch net/bpf/test_run.c:335 [inline] bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363 bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376 bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736 __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115 __do_sys_bpf kernel/bpf/syscall.c:5201 [inline] __se_sys_bpf kernel/bpf/syscall.c:5199 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199
--- net/ipv4/route.c | 3 +++ 1 file changed, 3 insertions(+)
net/ipv4/route.c +3 -0
@@ -2173,6 +2173,9 @@ int ip_route_use_hint(struct sk_buff *skb, __be32 daddr, __be32 saddr,int err = -EINVAL ;u32 tag =0 ; +if (!in_dev) +return -EINVAL ; +if (ipv4_is_multicast (saddr) ||ipv4_is_lbcast (saddr)) goto martian_source;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 26/80 net: usb: ax88179_178a: stop lying about skb->truesize
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 4ce62d5b2f7aecd4900e7d6115588ad7f9acccca ]
Some usb drivers try to set small skb->truesize and break core networking stacks.
In this patch, I removed one of the skb->truesize overide.
I also replaced one skb_clone() by an allocation of a fresh and small skb, to get minimally sized skbs, like we did in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize in rx path")
--- drivers/net/usb/ax88179_178a.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)
drivers/net/usb/ax88179_178a.c +3 -8
@@ -1478,21 +1478,16 @@ static int ax88179_rx_fixup(struct usbnet *dev, struct sk_buff *skb)/* Skip IP alignment pseudo header */ skb_pull (skb,2 ); - skb->truesize =SKB_TRUESIZE (pkt_len_plus_padd);ax88179_rx_checksum (skb, pkt_hdr);return 1 ; } - ax_skb =skb_clone (skb,GFP_ATOMIC ); + ax_skb =netdev_alloc_skb_ip_align (dev->net, pkt_len);if (!ax_skb)return 0 ; -skb_trim (ax_skb, pkt_len); +skb_put (ax_skb, pkt_len); +memcpy (ax_skb->data, skb->data +2 , pkt_len); -/* Skip IP alignment pseudo header */ -skb_pull (ax_skb,2 ); - - skb->truesize = pkt_len_plus_padd + -SKB_DATA_ALIGN (sizeof (struct sk_buff ));ax88179_rx_checksum (ax_skb, pkt_hdr);usbnet_skb_return (dev, ax_skb);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 27/80 net: gtp: Fix Use-After-Free in gtp_dellink
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hyunwoo Kim <[email protected]>
[ Upstream commit f2a904107ee2b647bb7794a1a82b67740d7c8a64 ]
Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of gtp_dellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free.
To prevent this, it should be changed to hlist_for_each_entry_safe.
--- drivers/net/gtp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/gtp.c +2 -1
@@ -713,11 +713,12 @@ static int gtp_newlink(struct net *src_net, struct net_device *dev,static void gtp_dellink (struct net_device *dev,struct list_head *head) {struct gtp_dev *gtp =netdev_priv (dev); +struct hlist_node *next;struct pdp_ctx *pctx;int i;for (i =0 ; i < gtp->hash_size; i++) -hlist_for_each_entry_rcu (pctx, >p->tid_hash[i], hlist_tid) +hlist_for_each_entry_safe (pctx, next, >p->tid_hash[i], hlist_tid)pdp_context_delete (pctx);list_del_rcu (>p->list);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 28/80 ipvs: Fix checksumming on GSO of SCTP packets
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ismael Luceno <[email protected]>
[ Upstream commit e10d3ba4d434ed172914617ed8d74bd411421193 ]
It was observed in the wild that pairs of consecutive packets would leave the IPVS with the same wrong checksum, and the issue only went away when disabling GSO.
IPVS needs to avoid computing the SCTP checksum when using GSO.
--- net/netfilter/ipvs/ip_vs_proto_sctp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/netfilter/ipvs/ip_vs_proto_sctp.c +4 -2
@@ -126,7 +126,8 @@ sctp_snat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp,if (sctph->source != cp->vport || payload_csum || skb->ip_summed ==CHECKSUM_PARTIAL ) { sctph->source = cp->vport; -sctp_nat_csum (skb, sctph, sctphoff); +if (!skb_is_gso (skb) || !skb_is_gso_sctp (skb)) +sctp_nat_csum (skb, sctph, sctphoff); }else { skb->ip_summed =CHECKSUM_UNNECESSARY ; }
@@ -174,7 +175,8 @@ sctp_dnat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp, (skb->ip_summed == CHECKSUM_PARTIAL && !(skb_dst(skb)->dev->features & NETIF_F_SCTP_CRC))) { sctph->dest = cp->dport; -sctp_nat_csum (skb, sctph, sctphoff); +if (!skb_is_gso (skb) || !skb_is_gso_sctp (skb)) +sctp_nat_csum (skb, sctph, sctphoff); } else if (skb->ip_summed != CHECKSUM_PARTIAL) { skb->ip_summed =CHECKSUM_UNNECESSARY ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 29/80 net: openvswitch: Fix Use-After-Free in ovs_ct_exit
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hyunwoo Kim <[email protected]>
[ Upstream commit 5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2 ]
Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal of ovs_ct_limit_exit, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free.
To prevent this, it should be changed to hlist_for_each_entry_safe.
--- net/openvswitch/conntrack.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/openvswitch/conntrack.c +2 -2
@@ -1913,9 +1913,9 @@ static void ovs_ct_limit_exit(struct net *net, struct ovs_net *ovs_net)for (i =0 ; i <CT_LIMIT_HASH_BUCKETS ; ++i) {struct hlist_head *head = &info->limits[i];struct ovs_ct_limit *ct_limit; +struct hlist_node *next; -hlist_for_each_entry_rcu (ct_limit, head, hlist_node, -lockdep_ovsl_is_held ()) +hlist_for_each_entry_safe (ct_limit, next, head, hlist_node)kfree_rcu (ct_limit, rcu); }kfree (info->limits);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 30/80 mlxsw: spectrum_acl_tcam: Fix race during rehash delayed work
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit d90cfe20562407d9f080d24123078d666d730707 ]
The purpose of the rehash delayed work is to reduce the number of masks (eRPs) used by an ACL region as the eRP bank is a global and limited resource.
This is done in three steps:
1. Creating a new set of masks and a new ACL region which will use the new masks and to which the existing filters will be migrated to. The new region is assigned to 'vregion->region' and the region from which the filters are migrated from is assigned to 'vregion->region2'.
2. Migrating all the filters from the old region to the new region.
3. Destroying the old region and setting 'vregion->region2' to NULL.
Only the second steps is performed under the 'vregion->lock' mutex although its comments says that among other things it "Protects consistency of region, region2 pointers".
This is problematic as the first step can race with filter insertion from user space that uses 'vregion->region', but under the mutex.
Fix by holding the mutex across the entirety of the delayed work and not only during the second step.
--- drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +2 -2
@@ -713,7 +713,9 @@ static void mlxsw_sp_acl_tcam_vregion_rehash_work(struct work_struct *work) rehash.dw.work);int credits =MLXSW_SP_ACL_TCAM_VREGION_REHASH_CREDITS ; +mutex_lock (&vregion->lock);mlxsw_sp_acl_tcam_vregion_rehash (vregion->mlxsw_sp, vregion, &credits); +mutex_unlock (&vregion->lock);if (credits <0 )/* Rehash gone out of credits so it was interrupted. * Schedule the work as soon as possible to continue.
@@ -1353,7 +1355,6 @@ mlxsw_sp_acl_tcam_vregion_migrate(struct mlxsw_sp *mlxsw_sp,int err, err2;trace_mlxsw_sp_acl_tcam_vregion_migrate (mlxsw_sp, vregion); -mutex_lock (&vregion->lock); err =mlxsw_sp_acl_tcam_vchunk_migrate_all (mlxsw_sp, vregion, ctx, credits);if (err) {
@@ -1373,7 +1374,6 @@ mlxsw_sp_acl_tcam_vregion_migrate(struct mlxsw_sp *mlxsw_sp,/* Let the rollback to be continued later on. */ } } -mutex_unlock (&vregion->lock);trace_mlxsw_sp_acl_tcam_vregion_migrate_end (mlxsw_sp, vregion);return err; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 31/80 mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit 79b5b4b18bc85b19d3a518483f9abbbe6d7b3ba4 ]
The rule activity update delayed work periodically traverses the list of configured rules and queries their activity from the device.
As part of this task it accesses the entry pointed by 'ventry->entry', but this entry can be changed concurrently by the rehash delayed work, leading to a use-after-free [1].
Fix by closing the race and perform the activity query under the 'vregion->lock' mutex.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181 CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Freed by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30
--- .../net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +8 -2
@@ -1189,8 +1189,14 @@ mlxsw_sp_acl_tcam_ventry_activity_get(struct mlxsw_sp *mlxsw_sp,struct mlxsw_sp_acl_tcam_ventry *ventry, bool *activity) { - return mlxsw_sp_acl_tcam_entry_activity_get(mlxsw_sp, - ventry->entry, activity); + struct mlxsw_sp_acl_tcam_vregion *vregion = ventry->vchunk->vregion; +int err; + +mutex_lock (&vregion->lock); + err =mlxsw_sp_acl_tcam_entry_activity_get (mlxsw_sp, ventry->entry, + activity); +mutex_unlock (&vregion->lock); +return err; } static int
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 32/80 mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit 54225988889931467a9b55fdbef534079b665519 ]
The rehash delayed work migrates filters from one region to another according to the number of available credits.
The migrated from region is destroyed at the end of the work if the number of credits is non-negative as the assumption is that this is indicative of migration being complete. This assumption is incorrect as a non-negative number of credits can also be the result of a failed migration.
The destruction of a region that still has filters referencing it can result in a use-after-free [1].
Fix by not destroying the region if migration failed.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858 CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70 mlxsw_sp_acl_atcam_entry_del+0x81/0x210 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 174: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Freed by task 7: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30
--- drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +1 -0
@@ -1481,6 +1481,7 @@ mlxsw_sp_acl_tcam_vregion_rehash(struct mlxsw_sp *mlxsw_sp, ctx, credits);if (err) {dev_err (mlxsw_sp->bus_info->dev,"Failed to migrate vregion\n" ); +return ; }if (*credits >=0 )
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 33/80 mlxsw: spectrum_acl_tcam: Rate limit error message
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit 5bcf925587e9b5d36420d572a0b4d131c90fb306 ]
In the rare cases when the device resources are exhausted it is likely that the rehash delayed work will fail. An error message will be printed whenever this happens which can be overwhelming considering the fact that the work is per-region and that there can be hundreds of regions.
Fix by rate limiting the error message.
--- drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +1 -1
@@ -1480,7 +1480,7 @@ mlxsw_sp_acl_tcam_vregion_rehash(struct mlxsw_sp *mlxsw_sp, err =mlxsw_sp_acl_tcam_vregion_migrate (mlxsw_sp, vregion, ctx, credits);if (err) { -dev_err (mlxsw_sp->bus_info->dev,"Failed to migrate vregion\n" ); +dev_err_ratelimited (mlxsw_sp->bus_info->dev,"Failed to migrate vregion\n" );return ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 34/80 mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit 8ca3f7a7b61393804c46f170743c3b839df13977 ]
The rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters.
If the migration fails, the code tries to migrate the filters back to the old region. However, the rollback itself can also fail in which case another migration will be erroneously performed. Besides the fact that this ping pong is not a very good idea, it also creates a problem.
Each virtual chunk references two chunks: The currently used one ('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the first holds the chunk we want to migrate filters to and the second holds the chunk we are migrating filters from.
The code currently assumes - but does not verify - that the backup chunk does not exist (NULL) if the currently used chunk does not reference the target region. This assumption breaks when we are trying to rollback a rollback, resulting in the backup chunk being overwritten and leaked [1].
Fix by not rolling back a failed rollback and add a warning to avoid future cases.
[1]
WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20 Modules linked in: CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:parman_destroy+0x17/0x20 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_region_fini+0x19/0x60 mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK>
--- drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +4 -0
@@ -1230,6 +1230,8 @@ mlxsw_sp_acl_tcam_vchunk_migrate_start(struct mlxsw_sp *mlxsw_sp, {struct mlxsw_sp_acl_tcam_chunk *new_chunk; +WARN_ON (vchunk->chunk2); + new_chunk =mlxsw_sp_acl_tcam_chunk_create (mlxsw_sp, vchunk, region);if (IS_ERR (new_chunk))return PTR_ERR (new_chunk);
@@ -1364,6 +1366,8 @@ mlxsw_sp_acl_tcam_vregion_migrate(struct mlxsw_sp *mlxsw_sp, err =mlxsw_sp_acl_tcam_vchunk_migrate_all (mlxsw_sp, vregion, ctx, credits);if (err) { +if (ctx->this_is_rollback) +return err;/* In case migration was not successful, we need to swap * so the original region pointer is assigned again * to vregion->region.
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 35/80 mlxsw: spectrum_acl_tcam: Fix warning during rehash
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit 743edc8547a92b6192aa1f1b6bb78233fa21dc9b ]
As previously explained, the rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters.
When the work runs out of credits it stores the current chunk and entry as markers in the per-work context so that it would know where to resume the migration from the next time the work is scheduled.
Upon error, the chunk marker is reset to NULL, but without resetting the entry markers despite being relative to it. This can result in migration being resumed from an entry that does not belong to the chunk being migrated. In turn, this will eventually lead to a chunk being iterated over as if it is an entry. Because of how the two structures happen to be defined, this does not lead to KASAN splats, but to warnings such as [1].
Fix by creating a helper that resets all the markers and call it from all the places the currently only reset the chunk marker. For good measures also call it when starting a completely new rehash. Add a warning to avoid future cases.
[1]
WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0 Modules linked in: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_afk_encode+0x242/0x2f0 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 </TASK>
--- .../mellanox/mlxsw/spectrum_acl_tcam.c | 20 ++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +17 -3
@@ -725,6 +725,17 @@ static void mlxsw_sp_acl_tcam_vregion_rehash_work(struct work_struct *work)mlxsw_sp_acl_tcam_vregion_rehash_work_schedule (vregion); } +static void +mlxsw_sp_acl_tcam_rehash_ctx_vchunk_reset (struct mlxsw_sp_acl_tcam_rehash_ctx *ctx) +{ +/* The entry markers are relative to the current chunk and therefore +* needs to be reset together with the chunk marker. +*/ + ctx->current_vchunk =NULL ; + ctx->start_ventry =NULL ; + ctx->stop_ventry =NULL ; +} +static void mlxsw_sp_acl_tcam_rehash_ctx_vchunk_changed (struct mlxsw_sp_acl_tcam_vchunk *vchunk) {
@@ -747,7 +758,7 @@ mlxsw_sp_acl_tcam_rehash_ctx_vregion_changed(struct mlxsw_sp_acl_tcam_vregion *v* the current chunk pointer to make sure all chunks * are properly migrated. */ - vregion->rehash.ctx.current_vchunk =NULL ; +mlxsw_sp_acl_tcam_rehash_ctx_vchunk_reset (&vregion->rehash.ctx); } static struct mlxsw_sp_acl_tcam_vregion *
@@ -1250,7 +1261,7 @@ mlxsw_sp_acl_tcam_vchunk_migrate_end(struct mlxsw_sp *mlxsw_sp, {mlxsw_sp_acl_tcam_chunk_destroy (mlxsw_sp, vchunk->chunk2); vchunk->chunk2 =NULL ; - ctx->current_vchunk =NULL ; +mlxsw_sp_acl_tcam_rehash_ctx_vchunk_reset (ctx); } static int
@@ -1282,6 +1293,8 @@ mlxsw_sp_acl_tcam_vchunk_migrate_one(struct mlxsw_sp *mlxsw_sp, ventry =list_first_entry (&vchunk->ventry_list,typeof (*ventry), list); +WARN_ON (ventry->vchunk != vchunk); +list_for_each_entry_from (ventry, &vchunk->ventry_list, list) {/* During rollback, once we reach the ventry that failed * to migrate, we are done.
@@ -1373,7 +1386,7 @@ mlxsw_sp_acl_tcam_vregion_migrate(struct mlxsw_sp *mlxsw_sp,* to vregion->region. */ swap (vregion->region, vregion->region2); - ctx->current_vchunk =NULL ; +mlxsw_sp_acl_tcam_rehash_ctx_vchunk_reset (ctx); ctx->this_is_rollback = true; err2 =mlxsw_sp_acl_tcam_vchunk_migrate_all (mlxsw_sp, vregion, ctx, credits);
@@ -1432,6 +1445,7 @@ mlxsw_sp_acl_tcam_vregion_rehash_start(struct mlxsw_sp *mlxsw_sp, ctx->hints_priv = hints_priv; ctx->this_is_rollback = false; +mlxsw_sp_acl_tcam_rehash_ctx_vchunk_reset (ctx);return 0 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 36/80 mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit b377add0f0117409c418ddd6504bd682ebe0bf79 ]
Both the function that migrates all the chunks within a region and the function that migrates all the entries within a chunk call list_first_entry() on the respective lists without checking that the lists are not empty. This is incorrect usage of the API, which leads to the following warning [1].
Fix by returning if the lists are empty as there is nothing to migrate in this case.
[1]
WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0> Modules linked in: CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0 [...] Call Trace: <TASK> mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK>
--- drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +7 -0
@@ -1284,6 +1284,9 @@ mlxsw_sp_acl_tcam_vchunk_migrate_one(struct mlxsw_sp *mlxsw_sp,return 0 ; } +if (list_empty (&vchunk->ventry_list)) + goto out; +/* If the migration got interrupted, we have the ventry to start from * stored in context. */
@@ -1335,6 +1338,7 @@ mlxsw_sp_acl_tcam_vchunk_migrate_one(struct mlxsw_sp *mlxsw_sp, } } +out:mlxsw_sp_acl_tcam_vchunk_migrate_end (mlxsw_sp, vchunk, ctx);return 0 ; }
@@ -1348,6 +1352,9 @@ mlxsw_sp_acl_tcam_vchunk_migrate_all(struct mlxsw_sp *mlxsw_sp,struct mlxsw_sp_acl_tcam_vchunk *vchunk;int err; +if (list_empty (&vregion->vchunk_list)) +return 0 ; +/* If the migration got interrupted, we have the vchunk * we are working on stored in context. */
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 37/80 mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit fb4e2b70a7194b209fc7320bbf33b375f7114bd5 ]
The rehash delayed work is rescheduled with a delay if the number of credits at end of the work is not negative as supposedly it means that the migration ended. Otherwise, it is rescheduled immediately.
After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash" the above is no longer accurate as a non-negative number of credits is no longer indicative of the migration being done. It can also happen if the work encountered an error in which case the migration will resume the next time the work is scheduled.
The significance of the above is that it is possible for the work to be pending and associated with hints that were allocated when the migration started. This leads to the hints being leaked [1] when the work is canceled while pending as part of ACL region dismantle.
Fix by freeing the hints if hints are associated with a work that was canceled while pending.
Blame the original commit since the reliance on not having a pending work associated with hints is fragile.
[1]
unreferenced object 0xffff88810e7c3000 (size 256):
comm "kworker/0:16", pid 176, jiffies 4295460353 hex dump (first 32 bytes):
00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a.......
00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@...........
backtrace (crc 2544ddb9):
[<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0
[<000000004d9a1ad9>] objagg_hints_get+0x42/0x390
[<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400
[<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160
[<00000000e81fd734>] process_one_work+0x59c/0xf20
[<00000000ceee9e81>] worker_thread+0x799/0x12c0
[<00000000bda6fe39>] kthread+0x246/0x300
[<0000000070056d23>] ret_from_fork+0x34/0x70
[<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30--- drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +5 -1
@@ -831,10 +831,14 @@ mlxsw_sp_acl_tcam_vregion_destroy(struct mlxsw_sp *mlxsw_sp,struct mlxsw_sp_acl_tcam *tcam = vregion->tcam;if (vgroup->vregion_rehash_enabled && ops->region_rehash_hints_get) { +struct mlxsw_sp_acl_tcam_rehash_ctx *ctx = &vregion->rehash.ctx; +mutex_lock (&tcam->lock);list_del (&vregion->tlist);mutex_unlock (&tcam->lock); -cancel_delayed_work_sync (&vregion->rehash.dw); +if (cancel_delayed_work_sync (&vregion->rehash.dw) && + ctx->hints_priv) + ops->region_rehash_hints_put (ctx->hints_priv); }mlxsw_sp_acl_tcam_vgroup_vregion_detach (mlxsw_sp, vregion);if (vregion->region2)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 38/80 netfilter: nf_tables: honor table dormant flag from netdev release event path
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
[ Upstream commit 8e30abc9ace4f0add4cd761dfdbfaebae5632dd2 ]
Check for table dormant flag otherwise netdev release event path tries to unregister an already unregistered hook.
[524854.857999] ------------[ cut here ]------------ [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365 [524854.858869] Workqueue: netns cleanup_net [524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260 [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005 [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Call Trace: [524854.859006] <TASK> [524854.859013] ? __warn+0x9f/0x1a0 [524854.859027] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859044] ? report_bug+0x1b1/0x1e0 [524854.859060] ? handle_bug+0x3c/0x70 [524854.859071] ? exc_invalid_op+0x17/0x40 [524854.859083] ? asm_exc_invalid_op+0x1a/0x20 [524854.859100] ? __nf_unregister_net_hook+0x6a/0x260 [524854.859116] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables] [524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859461] ? packet_notifier+0xb3/0x360 [524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40 [524854.859489] ? dcbnl_netdevice_event+0x35/0x140 [524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859661] notifier_call_chain+0x7d/0x140 [524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0
--- net/netfilter/nft_chain_filter.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/netfilter/nft_chain_filter.c +3 -1
@@ -336,7 +336,9 @@ static void nft_netdev_event(unsigned long event, struct net_device *dev,return ;if (n >1 ) { -nf_unregister_net_hook (ctx->net, &found->ops); +if (!(ctx->chain->table->flags &NFT_TABLE_F_DORMANT )) +nf_unregister_net_hook (ctx->net, &found->ops); +list_del_rcu (&found->list);kfree_rcu (found, rcu);return ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 39/80 i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sindhu Devale <[email protected]>
[ Upstream commit 2cc7d150550cc981aceedf008f5459193282425c ]
Issue reported by customer during SRIOV testing, call trace:
When both i40e and the i40iw driver are loaded, a warning in check_flush_dependency is being triggered. This seems to be because of the i40e driver workqueue is allocated with the WQ_MEM_RECLAIM flag, and the i40iw one is not.
Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too.
[Feb 9 09:08] ------------[ cut here ]------------
[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is flushing !WQ_MEM_RECLAIM infiniband:0x0
[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966 check_flush_dependency+0x10b/0x120
[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod fuse
[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020
[ +0.000001] Workqueue: i40e i40e_service_task [i40e] [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120 [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
0000000000000027
[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:ffff94d47f620bc0
[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:00000000ffff7fff
[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:ffff94c5451ea180
[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:ffff94c5f1330ab0
[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000) knlGS:0000000000000000
[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:00000000007706f0
[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ +0.000001] PKRU: 55555554 [ +0.000001] Call Trace: [ +0.000001] <TASK> [ +0.000002] ? __warn+0x80/0x130 [ +0.000003] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? report_bug+0x195/0x1a0 [ +0.000005] ? handle_bug+0x3c/0x70 [ +0.000003] ? exc_invalid_op+0x14/0x70 [ +0.000002] ? asm_exc_invalid_op+0x16/0x20 [ +0.000006] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? check_flush_dependency+0x10b/0x120 [ +0.000002] __flush_workqueue+0x126/0x3f0 [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core] [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core] [ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core] [ +0.000020] i40iw_close+0x4b/0x90 [irdma] [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e] [ +0.000035] i40e_service_task+0x126/0x190 [i40e] [ +0.000024] process_one_work+0x174/0x340 [ +0.000003] worker_thread+0x27e/0x390 [ +0.000001] ? __pfx_worker_thread+0x10/0x10 [ +0.000002] kthread+0xdf/0x110 [ +0.000002] ? __pfx_kthread+0x10/0x10 [ +0.000002] ret_from_fork+0x2d/0x50 [ +0.000003] ? __pfx_kthread+0x10/0x10 [ +0.000001] ret_from_fork_asm+0x1b/0x30 [ +0.000004] </TASK> [ +0.000001] ---[ end trace 0000000000000000 ]---
--- drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/i40e/i40e_main.c +1 -1
@@ -16690,7 +16690,7 @@ static int __init i40e_init_module(void)* since we need to be able to guarantee forward progress even under * memory pressure. */ - i40e_wq =alloc_workqueue ("%s" ,WQ_MEM_RECLAIM ,0 , i40e_driver_name); + i40e_wq =alloc_workqueue ("%s" ,0 ,0 , i40e_driver_name);if (!i40e_wq) {pr_err ("%s: Failed to create workqueue\n" , i40e_driver_name);return -ENOMEM ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 40/80 i40e: Report MFS in decimal base instead of hex
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Erwan Velu <[email protected]>
[ Upstream commit ef3c313119ea448c22da10366faa26b5b4b1a18e ]
If the MFS is set below the default (0x2600), a warning message is reported like the following :
MFS for port 1 has been set below the default: 600
This message is a bit confusing as the number shown here (600) is in fact an hexa number: 0x600 = 1536
Without any explicit "0x" prefix, this message is read like the MFS is set to 600 bytes.
MFS, as per MTUs, are usually expressed in decimal base.
This commit reports both current and default MFS values in decimal so it's less confusing for end-users.
A typical warning message looks like the following :
MFS for port 1 (1536) has been set below the default (9728)
--- drivers/net/ethernet/intel/i40e/i40e_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/i40e/i40e_main.c +2 -2
@@ -16147,8 +16147,8 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent) val = (rd32 (&pf->hw,I40E_PRTGL_SAH ) &I40E_PRTGL_SAH_MFS_MASK ) >>I40E_PRTGL_SAH_MFS_SHIFT ;if (val <MAX_FRAME_SIZE_DEFAULT ) -dev_warn (&pdev->dev,"MFS for port %x has been set below the default: %x\n" , - pf->hw.port, val); +dev_warn (&pdev->dev,"MFS for port %x (%d) has been set below the default (%d)\n" , + pf->hw.port, val,MAX_FRAME_SIZE_DEFAULT );/* Add a filter to drop all Flow control frames from any VSI from being * transmitted. By doing so we stop a malicious VF from sending out
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 41/80 iavf: Fix TC config comparison with existing adapter TC config
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sudheer Mogilappagari <[email protected]>
[ Upstream commit 54976cf58d6168b8d15cebb395069f23b2f34b31 ]
Same number of TCs doesn't imply that underlying TC configs are same. The config could be different due to difference in number of queues in each TC. Add utility function to determine if TC configs are same.
--- drivers/net/ethernet/intel/iavf/iavf_main.c | 30 ++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/iavf/iavf_main.c +29 -1
@@ -2901,6 +2901,34 @@ static void iavf_del_all_cloud_filters(struct iavf_adapter *adapter)spin_unlock_bh (&adapter->cloud_filter_list_lock); } +/** +* iavf_is_tc_config_same - Compare the mqprio TC config with the +* TC config already configured on this adapter. +* @adapter: board private structure +* @mqprio_qopt: TC config received from kernel. +* +* This function compares the TC config received from the kernel +* with the config already configured on the adapter. +* +* Return: True if configuration is same, false otherwise. +**/ +static bool iavf_is_tc_config_same (struct iavf_adapter *adapter, +struct tc_mqprio_qopt *mqprio_qopt) +{ +struct virtchnl_channel_info *ch = &adapter->ch_config.ch_info[0 ]; +int i; + +if (adapter->num_tc != mqprio_qopt->num_tc) +return false; + +for (i =0 ; i < adapter->num_tc; i++) { +if (ch[i].count != mqprio_qopt->count[i] || + ch[i].offset != mqprio_qopt->offset[i]) +return false; + } +return true; +} +/** * __iavf_setup_tc - configure multiple traffic classes * @netdev: network interface device structure
@@ -2958,7 +2986,7 @@ static int __iavf_setup_tc(struct net_device *netdev, void *type_data)if (ret)return ret;/* Return if same TC config is requested */ -if (adapter->num_tc == num_tc) +if (iavf_is_tc_config_same (adapter, &mqprio_qopt->qopt))return 0 ; adapter->num_tc = num_tc;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 42/80 net: ethernet: ti: am65-cpts: Fix PTPv1 message type on TX packets
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Reeder <[email protected]>
[ Upstream commit 1b9e743e923b256e353a9a644195372285e5a6c0 ]
The CPTS, by design, captures the messageType (Sync, Delay_Req, etc.) field from the second nibble of the PTP header which is defined in the PTPv2 (1588-2008) specification. In the PTPv1 (1588-2002) specification the first two bytes of the PTP header are defined as the versionType which is always 0x0001. This means that any PTPv1 packets that are tagged for TX timestamping by the CPTS will have their messageType set to 0x0 which corresponds to a Sync message type. This causes issues when a PTPv1 stack is expecting a Delay_Req (messageType: 0x1) timestamp that never appears.
Fix this by checking if the ptp_class of the timestamped TX packet is PTP_CLASS_V1 and then matching the PTP sequence ID to the stored sequence ID in the skb->cb data structure. If the sequence IDs match and the packet is of type PTPv1 then there is a chance that the messageType has been incorrectly stored by the CPTS so overwrite the messageType stored by the CPTS with the messageType from the skb->cb data structure. This allows the PTPv1 stack to receive TX timestamps for Delay_Req packets which are necessary to lock onto a PTP Leader.
--- drivers/net/ethernet/ti/am65-cpts.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/ethernet/ti/am65-cpts.c +5 -0
@@ -649,6 +649,11 @@ static bool am65_cpts_match_tx_ts(struct am65_cpts *cpts,struct am65_cpts_skb_cb_data *skb_cb = (struct am65_cpts_skb_cb_data *)skb->cb; +if ((ptp_classify_raw (skb) &PTP_CLASS_V1 ) && + ((mtype_seqid &AM65_CPTS_EVENT_1_SEQUENCE_ID_MASK ) == + (skb_cb->skb_mtype_seqid &AM65_CPTS_EVENT_1_SEQUENCE_ID_MASK ))) + mtype_seqid = skb_cb->skb_mtype_seqid; +if (mtype_seqid == skb_cb->skb_mtype_seqid) {u64 ns = event->timestamp;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 43/80 af_unix: Suppress false-positive lockdep splat for spin_lock() in __unix_gc().
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 1971d13ffa84a551d29a81fdf5b5ec5be166ac83 ]
syzbot reported a lockdep splat regarding unix_gc_lock and unix_state_lock().
One is called from recvmsg() for a connected socket, and another is called from GC for TCP_LISTEN socket.
So, the splat is false-positive.
Let's add a dedicated lock class for the latter to suppress the splat.
Note that this change is not necessary for net-next.git as the issue is only applied to the old GC impl.
[0]:
WARNING: possible circular locking dependency detected 6.9.0-rc5-syzkaller-00007-g4d2008430ce8 #0 Not tainted
-----------------------------------------------------
kworker/u8:1/11 is trying to acquire lock:ffff88807cea4e70 (&u->lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff88807cea4e70 (&u->lock){+.+.}-{2:2}, at: __unix_gc+0x40e/0xf70 net/unix/garbage.c:302
but task is already holding lock:ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: __unix_gc+0x117/0xf70 net/unix/garbage.c:261
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (unix_gc_lock){+.+.}-{2:2}:
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
__raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
_raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:351 [inline]
unix_notinflight+0x13d/0x390 net/unix/garbage.c:140
unix_detach_fds net/unix/af_unix.c:1819 [inline]
unix_destruct_scm+0x221/0x350 net/unix/af_unix.c:1876
skb_release_head_state+0x100/0x250 net/core/skbuff.c:1188
skb_release_all net/core/skbuff.c:1200 [inline]
__kfree_skb net/core/skbuff.c:1216 [inline]
kfree_skb_reason+0x16d/0x3b0 net/core/skbuff.c:1252
kfree_skb include/linux/skbuff.h:1262 [inline]
manage_oob net/unix/af_unix.c:2672 [inline]
unix_stream_read_generic+0x1125/0x2700 net/unix/af_unix.c:2749
unix_stream_splice_read+0x239/0x320 net/unix/af_unix.c:2981
do_splice_read fs/splice.c:985 [inline]
splice_file_to_pipe+0x299/0x500 fs/splice.c:1295
do_splice+0xf2d/0x1880 fs/splice.c:1379
__do_splice fs/splice.c:1436 [inline]
__do_sys_splice fs/splice.c:1652 [inline]
__se_sys_splice+0x331/0x4a0 fs/splice.c:1634
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f-> #0 (&u->lock){+.+.}-{2:2}:
check_prev_add kernel/locking/lockdep.c:3134 [inline]
check_prevs_add kernel/locking/lockdep.c:3253 [inline]
validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
__lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
__raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
_raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:351 [inline]
__unix_gc+0x40e/0xf70 net/unix/garbage.c:302
process_one_work kernel/workqueue.c:3254 [inline]
process_scheduled_works+0xa10/0x17c0 kernel/workqueue.c:3335
worker_thread+0x86d/0xd70 kernel/workqueue.c:3416
kthread+0x2f0/0x390 kernel/kthread.c:388
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(unix_gc_lock);
lock(&u->lock);
lock(unix_gc_lock); lock(&u->lock);
*** DEADLOCK ***
3 locks held by kworker/u8:1/11:
#0: ffff888015089148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3229 [inline] #0: ffff888015089148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x17c0 kernel/workqueue.c:3335 #1: ffffc90000107d00 (unix_gc_work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3230 [inline]
#1: ffffc90000107d00 (unix_gc_work){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x17c0 kernel/workqueue.c:3335 #2: ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
#2: ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: __unix_gc+0x117/0xf70 net/unix/garbage.c:261
stack backtrace: CPU: 0 PID: 11 Comm: kworker/u8:1 Not tainted 6.9.0-rc5-syzkaller-00007-g4d2008430ce8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: events_unbound __unix_gc Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187 check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __unix_gc+0x40e/0xf70 net/unix/garbage.c:302 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa10/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f0/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>
--- include/net/af_unix.h | 3 +++ net/unix/garbage.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)
include/net/af_unix.h +3 -0
@@ -80,6 +80,9 @@ enum unix_socket_lock_class {U_LOCK_NORMAL ,U_LOCK_SECOND ,/* for double locking, see unix_state_double_lock(). */ U_LOCK_DIAG ,/* used while dumping icons, see sk_diag_dump_icons(). */ + U_LOCK_GC_LISTENER, /* used for listening socket while determining gc + * candidates to close a small race window. + */ }; static inline void unix_state_lock_nested(struct sock *sk,
net/unix/garbage.c +1 -1
@@ -260,7 +260,7 @@ void unix_gc(void)__set_bit (UNIX_GC_MAYBE_CYCLE , &u->gc_flags);if (sk->sk_state ==TCP_LISTEN ) { -unix_state_lock (sk); +unix_state_lock_nested (sk,U_LOCK_GC_LISTENER );unix_state_unlock (sk); } }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 44/80 serial: core: Provide port lock wrappers
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
[ Upstream commit b0af4bcb49464c221ad5f95d40f2b1b252ceedcc ]
When a serial port is used for kernel console output, then all modifications to the UART registers which are done from other contexts, e.g. getty, termios, are interference points for the kernel console.
So far this has been ignored and the printk output is based on the principle of hope. The rework of the console infrastructure which aims to support threaded and atomic consoles, requires to mark sections which modify the UART registers as unsafe. This allows the atomic write function to make informed decisions and eventually to restore operational state. It also allows to prevent the regular UART code from modifying UART registers while printk output is in progress.
All modifications of UART registers are guarded by the UART port lock, which provides an obvious synchronization point with the console infrastructure.
Provide wrapper functions for spin_[un]lock*(port->lock) invocations so that the console mechanics can be applied later on at a single place and does not require to copy the same logic all over the drivers.
Stable-dep-of: 54c4ec5f8c47 ("serial: mxs-auart: add spinlock around changing cts state")
--- include/linux/serial_core.h | 79 +++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+)
include/linux/serial_core.h +79 -0
@@ -260,6 +260,85 @@ struct uart_port {void *private_data;/* generic platform data pointer */ }; +/** +* uart_port_lock - Lock the UART port +* @up: Pointer to UART port structure +*/ +static inline void uart_port_lock (struct uart_port *up) +{ +spin_lock (&up->lock); +} + +/** +* uart_port_lock_irq - Lock the UART port and disable interrupts +* @up: Pointer to UART port structure +*/ +static inline void uart_port_lock_irq (struct uart_port *up) +{ +spin_lock_irq (&up->lock); +} + +/** +* uart_port_lock_irqsave - Lock the UART port, save and disable interrupts +* @up: Pointer to UART port structure +* @flags: Pointer to interrupt flags storage +*/ +static inline void uart_port_lock_irqsave (struct uart_port *up,unsigned long *flags) +{ +spin_lock_irqsave (&up->lock, *flags); +} + +/** +* uart_port_trylock - Try to lock the UART port +* @up: Pointer to UART port structure +* +* Returns: True if lock was acquired, false otherwise +*/ +static inline bool uart_port_trylock (struct uart_port *up) +{ +return spin_trylock (&up->lock); +} + +/** +* uart_port_trylock_irqsave - Try to lock the UART port, save and disable interrupts +* @up: Pointer to UART port structure +* @flags: Pointer to interrupt flags storage +* +* Returns: True if lock was acquired, false otherwise +*/ +static inline bool uart_port_trylock_irqsave (struct uart_port *up,unsigned long *flags) +{ +return spin_trylock_irqsave (&up->lock, *flags); +} + +/** +* uart_port_unlock - Unlock the UART port +* @up: Pointer to UART port structure +*/ +static inline void uart_port_unlock (struct uart_port *up) +{ +spin_unlock (&up->lock); +} + +/** +* uart_port_unlock_irq - Unlock the UART port and re-enable interrupts +* @up: Pointer to UART port structure +*/ +static inline void uart_port_unlock_irq (struct uart_port *up) +{ +spin_unlock_irq (&up->lock); +} + +/** +* uart_port_lock_irqrestore - Unlock the UART port, restore interrupts +* @up: Pointer to UART port structure +* @flags: The saved interrupt flags for restore +*/ +static inline void uart_port_unlock_irqrestore (struct uart_port *up,unsigned long flags) +{ +spin_unlock_irqrestore (&up->lock, flags); +} +static inline int serial_port_in (struct uart_port *up,int offset) {return up->serial_in (up, offset);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 45/80 serial: mxs-auart: add spinlock around changing cts state
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Emil Kronborg <[email protected]>
[ Upstream commit 54c4ec5f8c471b7c1137a1f769648549c423c026 ]
The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board.
[ 85.119255] ------------[ cut here ]------------
[ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
[ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
[ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
[ 85.151396] Hardware name: Freescale MXS (Device Tree)
[ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]
(...)
[ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
[ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
(...)--- drivers/tty/serial/mxs-auart.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/tty/serial/mxs-auart.c +6 -2
@@ -1094,11 +1094,13 @@ static void mxs_auart_set_ldisc(struct uart_port *port,static irqreturn_t mxs_auart_irq_handle (int irq,void *context) { -u32 istat; +u32 istat, stat;struct mxs_auart_port *s = context;u32 mctrl_temp = s->mctrl_prev; -u32 stat =mxs_read (s,REG_STAT ); +uart_port_lock (&s->port); + + stat =mxs_read (s,REG_STAT ); istat =mxs_read (s,REG_INTR );/* ack irq */
@@ -1134,6 +1136,8 @@ static irqreturn_t mxs_auart_irq_handle(int irq, void *context) istat &= ~AUART_INTR_TXIS ; } +uart_port_unlock (&s->port); +return IRQ_HANDLED ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 46/80 drm-print: add drm_dbg_driver to improve namespace symmetry
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jim Cromie <[email protected]>
[ Upstream commit 95a77b6331c2d2313aa843fa77ec91cd092ab0e4 ]
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}but not drm_dbg_driver itself, since it was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to drm_dbg_driver, and redef grandfathered name to symmetric one.
This will help with nouveau, which uses its own stack of macros to construct calls to dev_info, dev_dbg, etc, for which adaptation means drm_dbg_##driver constructs.
Stable-dep-of: a60ccade88f9 ("drm/vmwgfx: Fix crtc's atomic check conditional")
--- include/drm/drm_print.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
include/drm/drm_print.h +2 -1
@@ -444,7 +444,7 @@ void drm_dev_dbg(const struct device *dev, enum drm_debug_category category,#define drm_dbg_core (drm, fmt, ...) \ drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__) -#define drm_dbg (drm, fmt, ...) \ +#define drm_dbg_driver (drm, fmt, ...) \ drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)#define drm_dbg_kms (drm, fmt, ...) \ drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
@@ -463,6 +463,7 @@ void drm_dev_dbg(const struct device *dev, enum drm_debug_category category,#define drm_dbg_drmres (drm, fmt, ...) \ drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt, ##__VA_ARGS__) +#define drm_dbg (drm, fmt, ...) drm_dbg_driver(drm, fmt, ##__VA_ARGS__)/* * printk based logging
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 47/80 drm/vmwgfx: Fix crtcs atomic check conditional
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zack Rusin <[email protected]>
[ Upstream commit a60ccade88f926e871a57176e86a34bbf0db0098 ]
The conditional was supposed to prevent enabling of a crtc state without a set primary plane. Accidently it also prevented disabling crtc state with a set primary plane. Neither is correct.
Fix the conditional and just driver-warn when a crtc state has been enabled without a primary plane which will help debug broken userspace.
Fixes IGT's kms_atomic_interruptible and kms_atomic_transition tests.
--- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +8 -3
@@ -537,6 +537,7 @@ int vmw_du_cursor_plane_atomic_check(struct drm_plane *plane,int vmw_du_crtc_atomic_check (struct drm_crtc *crtc,struct drm_atomic_state *state) { +struct vmw_private *vmw =vmw_priv (crtc->dev);struct drm_crtc_state *new_state =drm_atomic_get_new_crtc_state (state, crtc);struct vmw_display_unit *du =vmw_crtc_to_du (new_state->crtc);
@@ -544,9 +545,13 @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,bool has_primary = new_state->plane_mask &drm_plane_mask (crtc->primary); -/* We always want to have an active plane with an active CRTC */ -if (has_primary != new_state->enable) -return -EINVAL ; +/* +* This is fine in general, but broken userspace might expect +* some actual rendering so give a clue as why it's blank. +*/ +if (new_state->enable && !has_primary) +drm_dbg_driver (&vmw->drm, +"CRTC without a primary plane will be blank.\n" ); if (new_state->connector_mask != connector_mask &&
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 48/80 Revert "crypto: api - Disallow identical driver names"
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
This reverts commit a6fec6324f518991d63360693224b42e0ea3144f which is commit 27016f75f5ed47e2d8e0ca75a8ff1f40bc1a5e27 upstream.
It is reported to cause problems in older kernels due to some crypto drivers having the same name, so revert it here to fix the problems.
--- crypto/algapi.c | 1 - 1 file changed, 1 deletion(-)
crypto/algapi.c +0 -1
@@ -258,7 +258,6 @@ static struct crypto_larval *__crypto_re }if (!strcmp (q->cra_driver_name, alg->cra_name) || - !strcmp (q->cra_driver_name, alg->cra_driver_name) || !strcmp (q->cra_name, alg->cra_driver_name)) goto err; }
Greg Kroah-Hartman
maintainerPATCH 49/80 net/mlx5e: Fix a race in command alloc flow
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shifeng Li <[email protected]>
commit 8f5100da56b3980276234e812ce98d8f075194cd upstream.
Fix a cmd->ent use after free due to a race on command entry. Such race occurs when one of the commands releases its last refcount and frees its index and entry while another process running command flush flow takes refcount to this command entry. The process which handles commands flush may see this command as needed to be flushed if the other process allocated a ent->idx but didn't set ent to cmd->ent_arr in cmd_work_handler(). Fix it by moving the assignment of cmd->ent_arr into the spin lock.
[70013.081955] BUG: KASAN: use-after-free in mlx5_cmd_trigger_completions+0x1e2/0x4c0 [mlx5_core] [70013.081967] Write of size 4 at addr ffff88880b1510b4 by task kworker/26:1/1433361 [70013.081968] [70013.082028] Workqueue: events aer_isr [70013.082053] Call Trace: [70013.082067] dump_stack+0x8b/0xbb [70013.082086] print_address_description+0x6a/0x270 [70013.082102] kasan_report+0x179/0x2c0 [70013.082173] mlx5_cmd_trigger_completions+0x1e2/0x4c0 [mlx5_core] [70013.082267] mlx5_cmd_flush+0x80/0x180 [mlx5_core] [70013.082304] mlx5_enter_error_state+0x106/0x1d0 [mlx5_core] [70013.082338] mlx5_try_fast_unload+0x2ea/0x4d0 [mlx5_core] [70013.082377] remove_one+0x200/0x2b0 [mlx5_core] [70013.082409] pci_device_remove+0xf3/0x280 [70013.082439] device_release_driver_internal+0x1c3/0x470 [70013.082453] pci_stop_bus_device+0x109/0x160 [70013.082468] pci_stop_and_remove_bus_device+0xe/0x20 [70013.082485] pcie_do_fatal_recovery+0x167/0x550 [70013.082493] aer_isr+0x7d2/0x960 [70013.082543] process_one_work+0x65f/0x12d0 [70013.082556] worker_thread+0x87/0xb50 [70013.082571] kthread+0x2e9/0x3a0 [70013.082592] ret_from_fork+0x1f/0x40
The logical relationship of this error is as follows:
aer_recover_work | ent->work
-------------------------------------------+------------------------------
aer_recover_work_func |
|- pcie_do_recovery |
|- report_error_detected |
|- mlx5_pci_err_detected |cmd_work_handler
|- mlx5_enter_error_state | |- cmd_alloc_index
|- enter_error_state | |- lock cmd->alloc_lock
|- mlx5_cmd_flush | |- clear_bit
|- mlx5_cmd_trigger_completions| |- unlock cmd->alloc_lock
|- lock cmd->alloc_lock |
|- vector = ~dev->cmd.vars.bitmask
|- for_each_set_bit |
|- cmd_ent_get(cmd->ent_arr[i]) (UAF)
|- unlock cmd->alloc_lock | |- cmd->ent_arr[ent->idx]=entThe cmd->ent_arr[ent->idx] assignment and the bit clearing are not protected by the cmd->alloc_lock in cmd_work_handler().
--- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/cmd.c +7 -5
@@ -114,15 +114,18 @@ static u8 alloc_token(struct mlx5_cmd *creturn token; } -static int cmd_alloc_index (struct mlx5_cmd *cmd) +static int cmd_alloc_index (struct mlx5_cmd *cmd,struct mlx5_cmd_work_ent *ent) {unsigned long flags;int ret;spin_lock_irqsave (&cmd->alloc_lock, flags); ret =find_first_bit (&cmd->bitmask, cmd->max_reg_cmds); -if (ret < cmd->max_reg_cmds) +if (ret < cmd->max_reg_cmds) {clear_bit (ret, &cmd->bitmask); + ent->idx = ret; + cmd->ent_arr[ent->idx] = ent; + }spin_unlock_irqrestore (&cmd->alloc_lock, flags);return ret < cmd->max_reg_cmds ? ret : -ENOMEM ;
@@ -924,7 +927,7 @@ static void cmd_work_handler(struct work sem = ent->page_queue ? &cmd->pages_sem : &cmd->sem;down (sem);if (!ent->page_queue) { - alloc_ret =cmd_alloc_index (cmd); + alloc_ret =cmd_alloc_index (cmd, ent);if (alloc_ret <0 ) {mlx5_core_err_rl (dev,"failed to allocate command entry\n" );if (ent->callback) {
@@ -939,15 +942,14 @@ static void cmd_work_handler(struct workup (sem);return ; } - ent->idx = alloc_ret; }else { ent->idx = cmd->max_reg_cmds;spin_lock_irqsave (&cmd->alloc_lock, flags);clear_bit (ent->idx, &cmd->bitmask); + cmd->ent_arr[ent->idx] = ent;spin_unlock_irqrestore (&cmd->alloc_lock, flags); } - cmd->ent_arr[ent->idx] = ent; lay =get_inst (cmd, ent->idx); ent->lay = lay;memset (lay,0 ,sizeof (*lay));
Greg Kroah-Hartman
maintainerPATCH 50/80 tracing: Show size of requested perf buffer
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Robin H. Johnson <[email protected]>
commit a90afe8d020da9298c98fddb19b7a6372e2feb45 upstream.
If the perf buffer isn't large enough, provide a hint about how large it needs to be for whatever is running.
--- kernel/trace/trace_event_perf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/trace/trace_event_perf.c +2 -1
@@ -401,7 +401,8 @@ void *perf_trace_buf_alloc(int size, strBUILD_BUG_ON (PERF_MAX_TRACE_SIZE %sizeof (unsigned long ));if (WARN_ONCE (size >PERF_MAX_TRACE_SIZE , -"perf buffer not large enough" )) +"perf buffer not large enough, wanted %d, have %d" , + size,PERF_MAX_TRACE_SIZE ))return NULL ; *rctxp = rctx =perf_swevent_get_recursion_context ();
Greg Kroah-Hartman
maintainerPATCH 51/80 tracing: Increase PERF_MAX_TRACE_SIZE to handle Sentinel1 and docker together
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Robin H. Johnson <[email protected]>
commit e531e90b5ab0f7ce5ff298e165214c1aec6ed187 upstream.
Running endpoint security solutions like Sentinel1 that use perf-based tracing heavily lead to this repeated dump complaining about dockerd. The default value of 2048 is nowhere near not large enough.
Using the prior patch "tracing: show size of requested buffer", we get "perf buffer not large enough, wanted 6644, have 6144", after repeated up-sizing (I did 2/4/6/8K). With 8K, the problem doesn't occur at all, so below is the trace for 6K.
I'm wondering if this value should be selectable at boot time, but this is a good starting point.
``` ------------[ cut here ]------------ perf buffer not large enough, wanted 6644, have 6144 WARNING: CPU: 1 PID: 4997 at kernel/trace/trace_event_perf.c:402 perf_trace_buf_alloc+0x8c/0xa0 Modules linked in: [..] CPU: 1 PID: 4997 Comm: sh Tainted: G T 5.13.13-x86_64-00039-gb3959163488e #63 Hardware name: LENOVO 20KH002JUS/20KH002JUS, BIOS N23ET66W (1.41 ) 09/02/2019 RIP: 0010:perf_trace_buf_alloc+0x8c/0xa0 Code: 80 3d 43 97 d0 01 00 74 07 31 c0 5b 5d 41 5c c3 ba 00 18 00 00 89 ee 48 c7 c7 00 82 7d 91 c6 05 25 97 d0 01 01 e8 22 ee bc 00 <0f> 0b 31 c0 eb db 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 89 RSP: 0018:ffffb922026b7d58 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9da5ee012000 RCX: 0000000000000027 RDX: ffff9da881657828 RSI: 0000000000000001 RDI: ffff9da881657820 RBP: 00000000000019f4 R08: 0000000000000000 R09: ffffb922026b7b80 R10: ffffb922026b7b78 R11: ffffffff91dda688 R12: 000000000000000f R13: ffff9da5ee012108 R14: ffff9da8816570a0 R15: ffffb922026b7e30 FS: 00007f420db1a080(0000) GS:ffff9da881640000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000060 CR3: 00000002504a8006 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: kprobe_perf_func+0x11e/0x270 ? do_execveat_common.isra.0+0x1/0x1c0 ? do_execveat_common.isra.0+0x5/0x1c0 kprobe_ftrace_handler+0x10e/0x1d0 0xffffffffc03aa0c8 ? do_execveat_common.isra.0+0x1/0x1c0 do_execveat_common.isra.0+0x5/0x1c0 __x64_sys_execve+0x33/0x40 do_syscall_64+0x6b/0xc0 ? do_syscall_64+0x11/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f420dc1db37 Code: ff ff 76 e7 f7 d8 64 41 89 00 eb df 0f 1f 80 00 00 00 00 f7 d8 64 41 89 00 eb dc 0f 1f 84 00 00 00 00 00 b8 3b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 01 43 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd4e8b4e38 EFLAGS: 00000246 ORIG_RAX: 000000000000003b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f420dc1db37 RDX: 0000564338d1e740 RSI: 0000564338d32d50 RDI: 0000564338d28f00 RBP: 0000564338d28f00 R08: 0000564338d32d50 R09: 0000000000000020 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000564338d28f00 R13: 0000564338d32d50 R14: 0000564338d1e740 R15: 0000564338d28c60 ---[ end trace 83ab3e8e16275e49 ]--- ```
--- include/linux/trace_events.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/trace_events.h +1 -1
@@ -676,7 +676,7 @@ struct trace_event_file { } \ early_initcall(trace_init_perf_perm_##name); -#define PERF_MAX_TRACE_SIZE 2048 +#define PERF_MAX_TRACE_SIZE 8192#define MAX_FILTER_STR_VAL 256U/* Should handle KSYM_SYMBOL_LEN */
Greg Kroah-Hartman
maintainerPATCH 52/80 x86/cpu: Fix check for RDPKRU in __show_regs()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Kaplan <[email protected]>
commit b53c6bd5d271d023857174b8fd3e32f98ae51372 upstream.
cpu_feature_enabled(X86_FEATURE_OSPKE) does not necessarily reflect whether CR4.PKE is set on the CPU. In particular, they may differ on non-BSP CPUs before setup_pku() is executed. In this scenario, RDPKRU will #UD causing the system to hang.
Fix by checking CR4 for PKE enablement which is always correct for the current CPU.
The scenario happens by inserting a WARN* before setup_pku() in identiy_cpu() or some other diagnostic which would lead to calling __show_regs().
[ bp: Massage commit message. ]
--- arch/x86/kernel/process_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/process_64.c +1 -1
@@ -137,7 +137,7 @@ void __show_regs(struct pt_regs *regs, e log_lvl, d3, d6, d7); } -if (cpu_feature_enabled (X86_FEATURE_OSPKE )) +if (cr4 &X86_CR4_PKE )printk ("%sPKRU: %08x\n" , log_lvl,read_pkru ()); }
Greg Kroah-Hartman
maintainerPATCH 53/80 Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit 9bf4e919ccad613b3596eebf1ff37b05b6405307 upstream.
After an innocuous optimization change in LLVM main (19.0.0), x86_64 allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to build due to the checks in check_copy_size():
In file included from net/bluetooth/sco.c:27:
In file included from include/linux/module.h:13:
In file included from include/linux/stat.h:19:
In file included from include/linux/time.h:60:
In file included from include/linux/time32.h:13:
In file included from include/linux/timex.h:67:
In file included from arch/x86/include/asm/timex.h:6:
In file included from arch/x86/include/asm/tsc.h:10:
In file included from arch/x86/include/asm/msr.h:15:
In file included from include/linux/percpu.h:7:
In file included from include/linux/smp.h:118:
include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small
244 | __bad_copy_from();
| ^The same exact error occurs in l2cap_sock.c. The copy_to_user() statements that are failing come from l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This does not occur with GCC with or without KCSAN or Clang without KCSAN enabled.
len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build.
The official recommendation from LLVM developers is to consistently use long types for all size variables to avoid the unnecessary casting in the first place. Change the type of len to size_t in both l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears up the error while allowing min_t() to be replaced with min(), resulting in simpler code with no casts and fewer implicit conversions. While len is a different type than optlen now, it should result in no functional change because the result of sizeof() will clamp all values of optlen in the same manner as before.
--- net/bluetooth/l2cap_sock.c | 7 ++++--- net/bluetooth/sco.c | 7 ++++--- 2 files changed, 8 insertions(+), 6 deletions(-)
net/bluetooth/l2cap_sock.c +4 -3
@@ -456,7 +456,8 @@ static int l2cap_sock_getsockopt_old(strstruct l2cap_chan *chan =l2cap_pi (sk)->chan;struct l2cap_options opts;struct l2cap_conninfo cinfo; -int len, err =0 ; +int err =0 ; +size_t len;u32 opt;BT_DBG ("sk %p" , sk);
@@ -503,7 +504,7 @@ static int l2cap_sock_getsockopt_old(strBT_DBG ("mode 0x%2.2x" , chan->mode); - len = min_t(unsigned int, len, sizeof(opts)); + len =min (len,sizeof (opts));if (copy_to_user (optval, (char *) &opts, len)) err = -EFAULT ;
@@ -553,7 +554,7 @@ static int l2cap_sock_getsockopt_old(str cinfo.hci_handle = chan->conn->hcon->handle;memcpy (cinfo.dev_class, chan->conn->hcon->dev_class,3 ); - len = min_t(unsigned int, len, sizeof(cinfo)); + len =min (len,sizeof (cinfo));if (copy_to_user (optval, (char *) &cinfo, len)) err = -EFAULT ;
net/bluetooth/sco.c +4 -3
@@ -904,7 +904,8 @@ static int sco_sock_getsockopt_old(strucstruct sock *sk = sock->sk;struct sco_options opts;struct sco_conninfo cinfo; -int len, err =0 ; +int err =0 ; +size_t len;BT_DBG ("sk %p" , sk);
@@ -926,7 +927,7 @@ static int sco_sock_getsockopt_old(strucBT_DBG ("mtu %u" , opts.mtu); - len = min_t(unsigned int, len, sizeof(opts)); + len =min (len,sizeof (opts));if (copy_to_user (optval, (char *)&opts, len)) err = -EFAULT ;
@@ -944,7 +945,7 @@ static int sco_sock_getsockopt_old(struc cinfo.hci_handle =sco_pi (sk)->conn->hcon->handle;memcpy (cinfo.dev_class,sco_pi (sk)->conn->hcon->dev_class,3 ); - len = min_t(unsigned int, len, sizeof(cinfo)); + len =min (len,sizeof (cinfo));if (copy_to_user (optval, (char *)&cinfo, len)) err = -EFAULT ;
Greg Kroah-Hartman
maintainerPATCH 54/80 Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x0bda:0x4853
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: WangYuli <[email protected]>
commit d1a5a7eede2977da3d2002d5ea3b519019cc1a98 upstream.
Add the support ID(0x0bda, 0x4853) to usb_device_id table for Realtek RTL8852BE.
Without this change the device utilizes an obsolete version of the firmware that is encoded in it rather than the updated Realtek firmware and config files from the firmware directory. The latter files implement many new features.
The device table is as follows:
T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=4853 Rev= 0.00
S: Manufacturer=Realtek
S: Product=Bluetooth Radio
S: SerialNumber=00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
--- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/bluetooth/btusb.c +2 -0
@@ -439,6 +439,8 @@ static const struct usb_device_id blackl/* Realtek 8852BE Bluetooth devices */ { USB_DEVICE(0x0cb8, 0xc559), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x0bda, 0x4853), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x0bda, 0x887b), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x0bda, 0xb85b), .driver_info = BTUSB_REALTEK |
Greg Kroah-Hartman
maintainerPATCH 55/80 Bluetooth: qca: fix NULL-deref on non-serdev suspend
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 73e87c0a49fda31d7b589edccf4c72e924411371 upstream.
Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL.
Add the missing sanity check to prevent a NULL-pointer dereference when wakeup() is called for a non-serdev controller during suspend.
Just return true for now to restore the original behaviour and address the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") that causes the crash to happen already at setup() time.
--- drivers/bluetooth/hci_qca.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/bluetooth/hci_qca.c +3 -0
@@ -1590,6 +1590,9 @@ static bool qca_prevent_wake(struct hci_struct hci_uart *hu =hci_get_drvdata (hdev);bool wakeup; +if (!hu->serdev) +return true; +/* BT SoC attached through the serial bus is handled by the serdev driver. * So we need to use the device handle of the serdev driver to get the * status of device may wakeup.
Greg Kroah-Hartman
maintainerPATCH 56/80 mmc: sdhci-msm: pervent access to suspended controller
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mantas Pucka <[email protected]>
commit f8def10f73a516b771051a2f70f2f0446902cb4f upstream.
Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.
--- drivers/mmc/host/sdhci-msm.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
drivers/mmc/host/sdhci-msm.c +15 -1
@@ -2827,6 +2827,11 @@ static __maybe_unused int sdhci_msm_runtstruct sdhci_host *host =dev_get_drvdata (dev);struct sdhci_pltfm_host *pltfm_host =sdhci_priv (host);struct sdhci_msm_host *msm_host =sdhci_pltfm_priv (pltfm_host); +unsigned long flags; + +spin_lock_irqsave (&host->lock, flags); + host->runtime_suspended = true; +spin_unlock_irqrestore (&host->lock, flags);/* Drop the performance vote */ dev_pm_opp_set_rate (dev,0 );
@@ -2841,6 +2846,7 @@ static __maybe_unused int sdhci_msm_runtstruct sdhci_host *host =dev_get_drvdata (dev);struct sdhci_pltfm_host *pltfm_host =sdhci_priv (host);struct sdhci_msm_host *msm_host =sdhci_pltfm_priv (pltfm_host); +unsigned long flags;int ret; ret = clk_bulk_prepare_enable(ARRAY_SIZE(msm_host->bulk_clks),
@@ -2859,7 +2865,15 @@ static __maybe_unused int sdhci_msm_runtdev_pm_opp_set_rate (dev, msm_host->clk_rate); -return sdhci_msm_ice_resume (msm_host); + ret =sdhci_msm_ice_resume (msm_host); +if (ret) +return ret; + +spin_lock_irqsave (&host->lock, flags); + host->runtime_suspended = false; +spin_unlock_irqrestore (&host->lock, flags); + +return ret; }static const struct dev_pm_ops sdhci_msm_pm_ops = {
Greg Kroah-Hartman
maintainerPATCH 57/80 btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Thumshirn <[email protected]>
commit 2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf upstream.
Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino():
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
__kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000
This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory.
Fix this by using kvzalloc() which zeroes out the memory on allocation.
--- fs/btrfs/backref.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)
fs/btrfs/backref.c +3 -9
@@ -2315,20 +2315,14 @@ struct btrfs_data_container *init_data_csize_t alloc_bytes; alloc_bytes =max_t (size_t, total_bytes,sizeof (*data)); - data =kvmalloc (alloc_bytes,GFP_KERNEL ); + data =kvzalloc (alloc_bytes,GFP_KERNEL );if (!data)return ERR_PTR (-ENOMEM ); -if (total_bytes >=sizeof (*data)) { +if (total_bytes >=sizeof (*data)) data->bytes_left = total_bytes -sizeof (*data); - data->bytes_missing =0 ; - }else { +else data->bytes_missing =sizeof (*data) - total_bytes; - data->bytes_left =0 ; - } - - data->elem_cnt =0 ; - data->elem_missed =0 ;return data; }
Greg Kroah-Hartman
maintainerPATCH 58/80 cpu: Re-enable CPU mitigations by default for !X86 architectures
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit fe42754b94a42d08cf9501790afc25c4f6a5f631 upstream.
Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to turn mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta missed that "cpu_mitigations" is completely generic, whereas SPECULATION_MITIGATIONS is x86-specific.
Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it select CPU_MITIGATIONS, as having two configs for the same thing is unnecessary and confusing. This will also allow x86 to use the knob to manage mitigations that aren't strictly related to speculative execution.
Use another Kconfig to communicate to common code that CPU_MITIGATIONS is already defined instead of having x86's menu depend on the common CPU_MITIGATIONS. This allows keeping a single point of contact for all of x86's mitigations, and it's not clear that other architectures *want* to allow disabling mitigations at compile-time.
--- arch/Kconfig | 8 ++++++++ arch/x86/Kconfig | 11 ++++++----- kernel/cpu.c | 4 ++-- 3 files changed, 16 insertions(+), 7 deletions(-)
arch/Kconfig +8 -0
@@ -9,6 +9,14 @@ # source "arch/$(SRCARCH)/Kconfig" +config ARCH_CONFIGURES_CPU_MITIGATIONS + bool + +if !ARCH_CONFIGURES_CPU_MITIGATIONS +config CPU_MITIGATIONS + def_bool y +endif + menu "General architecture-dependent options" config CRASH_CORE
arch/x86/Kconfig +6 -5
@@ -61,6 +61,7 @@ config X86 select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI select ARCH_32BIT_OFF_T if X86_32 select ARCH_CLOCKSOURCE_INIT + select ARCH_CONFIGURES_CPU_MITIGATIONS select ARCH_ENABLE_HUGEPAGE_MIGRATION if X86_64 && HUGETLB_PAGE && MIGRATION select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 || (X86_32 && HIGHMEM) select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
@@ -2394,17 +2395,17 @@ config CC_HAS_SLS config CC_HAS_RETURN_THUNK def_bool $(cc-option,-mfunction-return=thunk-extern) -menuconfig SPECULATION_MITIGATIONS - bool "Mitigations for speculative execution vulnerabilities" +menuconfig CPU_MITIGATIONS + bool "Mitigations for CPU vulnerabilities" default y help - Say Y here to enable options which enable mitigations for - speculative execution hardware vulnerabilities. + Say Y here to enable options which enable mitigations for hardware + vulnerabilities (usually related to speculative execution). If you say N, all mitigations will be disabled. You really should know what you are doing to say so. -if SPECULATION_MITIGATIONS +if CPU_MITIGATIONS config PAGE_TABLE_ISOLATION bool "Remove the kernel mapping in user mode"
kernel/cpu.c +2 -2
@@ -2722,8 +2722,8 @@ enum cpu_mitigations { };static enum cpu_mitigations cpu_mitigations__ro_after_init = -IS_ENABLED (CONFIG_SPECULATION_MITIGATIONS ) ?CPU_MITIGATIONS_AUTO : -CPU_MITIGATIONS_OFF ; +IS_ENABLED (CONFIG_CPU_MITIGATIONS ) ?CPU_MITIGATIONS_AUTO : +CPU_MITIGATIONS_OFF ;static int __init mitigations_parse_cmdline (char *arg) {
Greg Kroah-Hartman
maintainerPATCH 59/80 arm64: dts: rockchip: enable internal pull-up for Q7_THRM# on RK3399 Puma
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Iskander Amara <[email protected]>
commit 0ac417b8f124427c90ec8c2ef4f632b821d924cc upstream.
Q7_THRM# pin is connected to a diode on the module which is used as a level shifter, and the pin have a pull-down enabled by default. We need to configure it to internal pull-up, other- wise whenever the pin is configured as INPUT and we try to control it externally the value will always remain zero.
--- arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +10 -0
@@ -396,6 +396,16 @@ }; &pinctrl { + pinctrl-names = "default"; + pinctrl-0 = <&q7_thermal_pin>; + + gpios { + q7_thermal_pin: q7-thermal-pin { + rockchip,pins = + <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>; + }; + }; + i2c8 { i2c8_xfer_a: i2c8-xfer { rockchip,pins =
Greg Kroah-Hartman
maintainerPATCH 60/80 drm/amdgpu/sdma5.2: use legacy HDP flush for SDMA2/3
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 9792b7cc18aaa0c2acae6af5d0acf249bcb1ab0d upstream.
This avoids a potential conflict with firmwares with the newer HDP flush mechanism.
--- drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-)
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c +14 -10
@@ -404,17 +404,21 @@ static void sdma_v5_2_ring_emit_hdp_flusu32 ref_and_mask =0 ;const struct nbio_hdp_flush_reg *nbio_hf_reg = adev->nbio.hdp_flush_reg; - ref_and_mask = nbio_hf_reg->ref_and_mask_sdma0 << ring->me; +if (ring->me >1 ) { +amdgpu_asic_flush_hdp (adev, ring); + }else { + ref_and_mask = nbio_hf_reg->ref_and_mask_sdma0 << ring->me; -amdgpu_ring_write (ring,SDMA_PKT_HEADER_OP (SDMA_OP_POLL_REGMEM ) | -SDMA_PKT_POLL_REGMEM_HEADER_HDP_FLUSH (1 ) | -SDMA_PKT_POLL_REGMEM_HEADER_FUNC (3 ));/* == */ -amdgpu_ring_write (ring, (adev->nbio.funcs->get_hdp_flush_done_offset (adev)) <<2 ); -amdgpu_ring_write (ring, (adev->nbio.funcs->get_hdp_flush_req_offset (adev)) <<2 ); -amdgpu_ring_write (ring, ref_and_mask);/* reference */ -amdgpu_ring_write (ring, ref_and_mask);/* mask */ -amdgpu_ring_write (ring,SDMA_PKT_POLL_REGMEM_DW5_RETRY_COUNT (0xfff ) | -SDMA_PKT_POLL_REGMEM_DW5_INTERVAL (10 ));/* retry count, poll interval */ +amdgpu_ring_write (ring,SDMA_PKT_HEADER_OP (SDMA_OP_POLL_REGMEM ) | +SDMA_PKT_POLL_REGMEM_HEADER_HDP_FLUSH (1 ) | +SDMA_PKT_POLL_REGMEM_HEADER_FUNC (3 ));/* == */ +amdgpu_ring_write (ring, (adev->nbio.funcs->get_hdp_flush_done_offset (adev)) <<2 ); +amdgpu_ring_write (ring, (adev->nbio.funcs->get_hdp_flush_req_offset (adev)) <<2 ); +amdgpu_ring_write (ring, ref_and_mask);/* reference */ +amdgpu_ring_write (ring, ref_and_mask);/* mask */ +amdgpu_ring_write (ring,SDMA_PKT_POLL_REGMEM_DW5_RETRY_COUNT (0xfff ) | +SDMA_PKT_POLL_REGMEM_DW5_INTERVAL (10 ));/* retry count, poll interval */ + } }/**
Greg Kroah-Hartman
maintainerPATCH 61/80 drm/amdgpu: Fix leak when GPU memory allocation fails
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mukul Joshi <[email protected]>
commit 25e9227c6afd200bed6774c866980b8e36d033af upstream.
Free the sync object if the memory allocation fails for any reason.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +1 -0
@@ -1502,6 +1502,7 @@ err_node_allow: err_bo_create:unreserve_mem_limit (adev, size, alloc_domain, !!sg); err_reserve_limit: +amdgpu_sync_free (&(*mem)->sync);mutex_destroy (&(*mem)->lock);if (gobj)drm_gem_object_put (gobj);
Greg Kroah-Hartman
maintainerPATCH 62/80 irqchip/gic-v3-its: Prevent double free on error
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guanrui Huang <[email protected]>
commit c26591afd33adce296c022e3480dea4282b7ef91 upstream.
The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again.
Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc().
[ tglx: Massaged change log ]
--- drivers/irqchip/irq-gic-v3-its.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-)
drivers/irqchip/irq-gic-v3-its.c +2 -7
@@ -4530,13 +4530,8 @@ static int its_vpe_irq_domain_alloc(struset_bit (i, bitmap); } -if (err) { -if (i >0 ) -its_vpe_irq_domain_free (domain, virq, i); - -its_lpi_free (bitmap, base, nr_ids); -its_free_prop_table (vprop_page); - } +if (err) +its_vpe_irq_domain_free (domain, virq, i);return err; }
Greg Kroah-Hartman
maintainerPATCH 63/80 ethernet: Add helper for assigning packet type when dest address does not match device address
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rahul Rameshbabu <[email protected]>
commit 6e159fd653d7ebf6290358e0330a0cb8a75cf73b upstream.
Enable reuse of logic in eth_type_trans for determining packet type.
--- include/linux/etherdevice.h | 25 +++++++++++++++++++++++++ net/ethernet/eth.c | 12 +----------- 2 files changed, 26 insertions(+), 11 deletions(-)
include/linux/etherdevice.h +25 -0
@@ -543,6 +543,31 @@ static inline unsigned long compare_ethe }/** +* eth_skb_pkt_type - Assign packet type if destination address does not match +* @skb: Assigned a packet type if address does not match @dev address +* @dev: Network device used to compare packet address against +* +* If the destination MAC address of the packet does not match the network +* device address, assign an appropriate packet type. +*/ +static inline void eth_skb_pkt_type (struct sk_buff *skb, +const struct net_device *dev) +{ +const struct ethhdr *eth =eth_hdr (skb); + +if (unlikely (!ether_addr_equal_64bits (eth->h_dest, dev->dev_addr))) { +if (unlikely (is_multicast_ether_addr_64bits (eth->h_dest))) { +if (ether_addr_equal_64bits (eth->h_dest, dev->broadcast)) + skb->pkt_type =PACKET_BROADCAST ; +else + skb->pkt_type =PACKET_MULTICAST ; + }else { + skb->pkt_type =PACKET_OTHERHOST ; + } + } +} + +/** * eth_skb_pad - Pad buffer to mininum number of octets for Ethernet frame * @skb: Buffer to pad *
net/ethernet/eth.c +1 -11
@@ -163,17 +163,7 @@ __be16 eth_type_trans(struct sk_buff *sk eth = (struct ethhdr *)skb->data;skb_pull_inline (skb,ETH_HLEN ); -if (unlikely (!ether_addr_equal_64bits (eth->h_dest, - dev->dev_addr))) { -if (unlikely (is_multicast_ether_addr_64bits (eth->h_dest))) { -if (ether_addr_equal_64bits (eth->h_dest, dev->broadcast)) - skb->pkt_type =PACKET_BROADCAST ; -else - skb->pkt_type =PACKET_MULTICAST ; - }else { - skb->pkt_type =PACKET_OTHERHOST ; - } - } +eth_skb_pkt_type (skb, dev);/* * Some variants of DSA tagging don't have an ethertype field
Greg Kroah-Hartman
maintainerPATCH 64/80 net: b44: set pause params only when interface is up
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Münster <[email protected]>
commit e3eb7dd47bd4806f00e104eb6da092c435f9fb21 upstream.
b44_free_rings() accesses b44::rx_buffers (and ::tx_buffers) unconditionally, but b44::rx_buffers is only valid when the device is up (they get allocated in b44_open(), and deallocated again in b44_close()), any other time these are just a NULL pointers.
So if you try to change the pause params while the network interface is disabled/administratively down, everything explodes (which likely netifd tries to do).
--- drivers/net/ethernet/broadcom/b44.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/net/ethernet/broadcom/b44.c +8 -6
@@ -2029,12 +2029,14 @@ static int b44_set_pauseparam(struct net bp->flags |=B44_FLAG_TX_PAUSE ; else bp->flags &= ~B44_FLAG_TX_PAUSE; -if (bp->flags &B44_FLAG_PAUSE_AUTO ) { -b44_halt (bp); -b44_init_rings (bp); -b44_init_hw (bp,B44_FULL_RESET ); - }else { -__b44_set_flow_ctrl (bp, bp->flags); +if (netif_running (dev)) { +if (bp->flags &B44_FLAG_PAUSE_AUTO ) { +b44_halt (bp); +b44_init_rings (bp); +b44_init_hw (bp,B44_FULL_RESET ); + }else { +__b44_set_flow_ctrl (bp, bp->flags); + } }spin_unlock_irq (&bp->lock);
Greg Kroah-Hartman
maintainerPATCH 65/80 stackdepot: respect __GFP_NOLOCKDEP allocation flag
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Ryabinin <[email protected]>
commit 6fe60465e1d53ea321ee909be26d97529e8f746c upstream.
If stack_depot_save_flags() allocates memory it always drops __GFP_NOLOCKDEP flag. So when KASAN tries to track __GFP_NOLOCKDEP allocation we may end up with lockdep splat like bellow:
======================================================
WARNING: possible circular locking dependency detected 6.9.0-rc3+ #49 Not tainted
------------------------------------------------------
kswapd0/149 is trying to acquire lock:
ffff88811346a920
(&xfs_nondir_ilock_class){++++}-{4:4}, at: xfs_reclaim_inode+0x3ac/0x590 [xfs]
but task is already holding lock:
ffffffff8bb33100 (fs_reclaim){+.+.}-{0:0}, at:balance_pgdat+0x5d9/0xad0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}-{0:0}:
__lock_acquire+0x7da/0x1030
lock_acquire+0x15d/0x400
fs_reclaim_acquire+0xb5/0x100
prepare_alloc_pages.constprop.0+0xc5/0x230
__alloc_pages+0x12a/0x3f0
alloc_pages_mpol+0x175/0x340
stack_depot_save_flags+0x4c5/0x510
kasan_save_stack+0x30/0x40
kasan_save_track+0x10/0x30
__kasan_slab_alloc+0x83/0x90
kmem_cache_alloc+0x15e/0x4a0
__alloc_object+0x35/0x370
__create_object+0x22/0x90
__kmalloc_node_track_caller+0x477/0x5b0
krealloc+0x5f/0x110
xfs_iext_insert_raw+0x4b2/0x6e0 [xfs]
xfs_iext_insert+0x2e/0x130 [xfs]
xfs_iread_bmbt_block+0x1a9/0x4d0 [xfs]
xfs_btree_visit_block+0xfb/0x290 [xfs]
xfs_btree_visit_blocks+0x215/0x2c0 [xfs]
xfs_iread_extents+0x1a2/0x2e0 [xfs]
xfs_buffered_write_iomap_begin+0x376/0x10a0 [xfs]
iomap_iter+0x1d1/0x2d0
iomap_file_buffered_write+0x120/0x1a0
xfs_file_buffered_write+0x128/0x4b0 [xfs]
vfs_write+0x675/0x890
ksys_write+0xc3/0x160
do_syscall_64+0x94/0x170
entry_SYSCALL_64_after_hwframe+0x71/0x79Always preserve __GFP_NOLOCKDEP to fix this.
--- lib/stackdepot.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
lib/stackdepot.c +2 -2
@@ -294,10 +294,10 @@ depot_stack_handle_t stack_depot_save(un/* * Zero out zone modifiers, as we don't have specific zone * requirements. Keep the flags related to allocation in atomic -* contexts and I/O. +* contexts, I/O, nolockdep. */ alloc_flags &= ~GFP_ZONEMASK ; - alloc_flags &= (GFP_ATOMIC |GFP_KERNEL ); + alloc_flags &= (GFP_ATOMIC |GFP_KERNEL | __GFP_NOLOCKDEP); alloc_flags |= __GFP_NOWARN; page =alloc_pages (alloc_flags,STACK_ALLOC_ORDER );if (page)
Greg Kroah-Hartman
maintainerPATCH 66/80 mtd: diskonchip: work around ubsan link failure
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit 21c9fb611c25d5cd038f6fe485232e7884bb0b3d upstream.
I ran into a randconfig build failure with UBSAN using gcc-13.2:
arm-linux-gnueabi-ld: error: unplaced orphan section .bss..Lubsan_data31' from drivers/mtd/nand/raw/diskonchip.o'
I'm not entirely sure what is going on here, but I suspect this has something to do with the check for the end of the doc_locations[] array that contains an (unsigned long)0xffffffff element, which is compared against the signed (int)0xffffffff. If this is the case, we should get a runtime check for undefined behavior, but we instead get an unexpected build-time error.
I would have expected this to work fine on 32-bit architectures despite the signed integer overflow, though on 64-bit architectures this likely won't ever work.
Changing the contition to instead check for the size of the array makes the code safe everywhere and avoids the ubsan check that leads to the link error. The loop code goes back to before 2.6.12.
--- drivers/mtd/nand/raw/diskonchip.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/mtd/nand/raw/diskonchip.c +2 -2
@@ -53,7 +53,7 @@ static unsigned long doc_locations[] __i 0xe8000, 0xea000, 0xec000, 0xee000, #endif #endif - 0xffffffff }; +}; static struct mtd_info *doclist = NULL;
@@ -1552,7 +1552,7 @@ static int __init init_nanddoc(void)if (ret <0 )return ret; }else { -for (i =0 ; (doc_locations[i] !=0xffffffff ); i++) { +for (i =0 ; i <ARRAY_SIZE (doc_locations); i++) {doc_probe (doc_locations[i]); } }
Greg Kroah-Hartman
maintainerPATCH 67/80 tcp: Clean up kernel listeners reqsk in inet_twsk_purge()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
commit 740ea3c4a0b2e326b23d7cdf05472a0e92aa39bc upstream.
Eric Dumazet reported a use-after-free related to the per-netns ehash series. [0]
When we create a TCP socket from userspace, the socket always holds a refcnt of the netns. This guarantees that a reqsk timer is always fired before netns dismantle. Each reqsk has a refcnt of its listener, so the listener is not freed before the reqsk, and the net is not freed before the listener as well.
OTOH, when in-kernel users create a TCP socket, it might not hold a refcnt of its netns. Thus, a reqsk timer can be fired after the netns dismantle and access freed per-netns ehash.
To avoid the use-after-free, we need to clean up TCP_NEW_SYN_RECV sockets in inet_twsk_purge() if the netns uses a per-netns ehash.
[0]: https://lore.kernel.org/netdev/CANn89iLXMup0dRD_Ov79Xt8N9FM0XdhCHEN05sf3eLwxKweM6w@mail.gmail.com/
BUG: KASAN: use-after-free in tcp_or_dccp_get_hashinfo include/net/inet_hashtables.h:181 [inline] BUG: KASAN: use-after-free in reqsk_queue_unlink+0x320/0x350 net/ipv4/inet_connection_sock.c:913 Read of size 8 at addr ffff88807545bd80 by task syz-executor.2/8301 CPU: 1 PID: 8301 Comm: syz-executor.2 Not tainted 6.0.0-syzkaller-02757-gaf7d23f9d96a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 tcp_or_dccp_get_hashinfo include/net/inet_hashtables.h:181 [inline] reqsk_queue_unlink+0x320/0x350 net/ipv4/inet_connection_sock.c:913 inet_csk_reqsk_queue_drop net/ipv4/inet_connection_sock.c:927 [inline] inet_csk_reqsk_queue_drop_and_put net/ipv4/inet_connection_sock.c:939 [inline] reqsk_timer_handler+0x724/0x1160 net/ipv4/inet_connection_sock.c:1053 call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790 __run_timers kernel/time/timer.c:1768 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803 __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571 invoke_softirq kernel/softirq.c:445 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1107 </IRQ>
--- net/ipv4/inet_timewait_sock.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
net/ipv4/inet_timewait_sock.c +14 -1
@@ -268,8 +268,21 @@ restart_rcu:rcu_read_lock (); restart:sk_nulls_for_each_rcu (sk, node, &head->chain) { -if (sk->sk_state !=TCP_TIME_WAIT ) +if (sk->sk_state !=TCP_TIME_WAIT ) { +/* A kernel listener socket might not hold refcnt for net, +* so reqsk_timer_handler() could be fired after net is +* freed. Userspace listener and reqsk never exist here. +*/ +if (unlikely (sk->sk_state ==TCP_NEW_SYN_RECV && + hashinfo->pernet)) { +struct request_sock *req =inet_reqsk (sk); + +inet_csk_reqsk_queue_drop_and_put (req->rsk_listener, req); + } +continue ; + } + tw =inet_twsk (sk);if ((tw->tw_family != family) ||refcount_read (&twsk_net (tw)->ns.count))
Greg Kroah-Hartman
maintainerPATCH 68/80 tcp: Fix NEW_SYN_RECV handling in inet_twsk_purge()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit 1c4e97dd2d3c9a3e84f7e26346aa39bc426d3249 upstream.
inet_twsk_purge() uses rcu to find TIME_WAIT and NEW_SYN_RECV objects to purge.
These objects use SLAB_TYPESAFE_BY_RCU semantic and need special care. We need to use refcount_inc_not_zero(&sk->sk_refcnt).
Reuse the existing correct logic I wrote for TIME_WAIT, because both structures have common locations for sk_state, sk_family, and netns pointer.
If after the refcount_inc_not_zero() the object fields longer match the keys, use sock_gen_put(sk) to release the refcount.
Then we can call inet_twsk_deschedule_put() for TIME_WAIT, inet_csk_reqsk_queue_drop_and_put() for NEW_SYN_RECV sockets, with BH disabled.
Then we need to restart the loop because we had drop rcu_read_lock().
--- net/ipv4/inet_timewait_sock.c | 41 +++++++++++++++++++---------------------- 1 file changed, 19 insertions(+), 22 deletions(-)
net/ipv4/inet_timewait_sock.c +19 -22
@@ -254,12 +254,12 @@ void __inet_twsk_schedule(struct inet_ti }EXPORT_SYMBOL_GPL (__inet_twsk_schedule); +/* Remove all non full sockets (TIME_WAIT and NEW_SYN_RECV) for dead netns */ void inet_twsk_purge (struct inet_hashinfo *hashinfo,int family) { -struct inet_timewait_sock *tw; -struct sock *sk;struct hlist_nulls_node *node;unsigned int slot; +struct sock *sk;for (slot =0 ; slot <= hashinfo->ehash_mask; slot++) {struct inet_ehash_bucket *head = &hashinfo->ehash[slot];
@@ -268,38 +268,35 @@ restart_rcu:rcu_read_lock (); restart:sk_nulls_for_each_rcu (sk, node, &head->chain) { -if (sk->sk_state !=TCP_TIME_WAIT ) { -/* A kernel listener socket might not hold refcnt for net, -* so reqsk_timer_handler() could be fired after net is -* freed. Userspace listener and reqsk never exist here. -*/ -if (unlikely (sk->sk_state ==TCP_NEW_SYN_RECV && - hashinfo->pernet)) { -struct request_sock *req =inet_reqsk (sk); - -inet_csk_reqsk_queue_drop_and_put (req->rsk_listener, req); - } +int state =inet_sk_state_load (sk); +if ((1 << state) & ~(TCPF_TIME_WAIT | +TCPF_NEW_SYN_RECV ))continue ; - } - tw =inet_twsk (sk); -if ((tw->tw_family != family) || -refcount_read (&twsk_net (tw)->ns.count)) +if (sk->sk_family != family || +refcount_read (&sock_net (sk)->ns.count))continue ; -if (unlikely (!refcount_inc_not_zero (&tw->tw_refcnt))) +if (unlikely (!refcount_inc_not_zero (&sk->sk_refcnt)))continue ; -if (unlikely ((tw->tw_family != family) || -refcount_read (&twsk_net (tw)->ns.count))) { -inet_twsk_put (tw); +if (unlikely (sk->sk_family != family || +refcount_read (&sock_net (sk)->ns.count))) { +sock_gen_put (sk); goto restart; }rcu_read_unlock ();local_bh_disable (); -inet_twsk_deschedule_put (tw); +if (state ==TCP_TIME_WAIT ) { +inet_twsk_deschedule_put (inet_twsk (sk)); + }else { +struct request_sock *req =inet_reqsk (sk); + +inet_csk_reqsk_queue_drop_and_put (req->rsk_listener, + req); + }local_bh_enable (); goto restart_rcu; }
Greg Kroah-Hartman
maintainerPATCH 69/80 dmaengine: owl: fix register access functions
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 43c633ef93a5d293c96ebcedb40130df13128428 ]
When building with 'make W=1', clang notices that the computed register values are never actually written back but instead the wrong variable is set:
drivers/dma/owl-dma.c:244:6: error: variable 'regval' set but not used [-Werror,-Wunused-but-set-variable]
244 | u32 regval;
| ^drivers/dma/owl-dma.c:268:6: error: variable 'regval' set but not used [-Werror,-Wunused-but-set-variable]
268 | u32 regval;
| ^
Change these to what was most likely intended.
--- drivers/dma/owl-dma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/dma/owl-dma.c +2 -2
@@ -249,7 +249,7 @@ static void pchan_update(struct owl_dma_pchan *pchan, u32 reg,else regval &= ~val; -writel (val, pchan->base + reg); +writel (regval, pchan->base + reg); }static void pchan_writel (struct owl_dma_pchan *pchan,u32 reg,u32 data)
@@ -273,7 +273,7 @@ static void dma_update(struct owl_dma *od, u32 reg, u32 val, bool state)else regval &= ~val; -writel (val, od->base + reg); +writel (regval, od->base + reg); }static void dma_writel (struct owl_dma *od,u32 reg,u32 data)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 70/80 idma64: Dont try to serve interrupts when device is powered off
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
[ Upstream commit 9140ce47872bfd89fca888c2f992faa51d20c2bc ]
When iDMA 64-bit device is powered off, the IRQ status register is all 1:s. This is never happen in real case and signalling that the device is simply powered off. Don't try to serve interrupts that are not ours.
--- drivers/dma/idma64.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/dma/idma64.c +4 -0
@@ -167,6 +167,10 @@ static irqreturn_t idma64_irq(int irq, void *dev)u32 status_err;unsigned short i; +/* Since IRQ may be shared, check if DMA controller is powered on */ +if (status ==GENMASK (31 ,0 )) +return IRQ_NONE ; +dev_vdbg (idma64->dma.dev,"%s: status=%#x\n" , __func__, status);/* Check if we have any interrupt from the DMA controller */
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 71/80 dma: xilinx_dpdma: Fix locking
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Anderson <[email protected]>
[ Upstream commit 244296cc3a155199a8b080d19e645d7d49081a38 ]
There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like
[ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: events_unbound deferred_probe_work_func [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [ 31.078550] sp : ffffffc083bb2e10 [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516 [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50/0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] do_take_over_console+0x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered+0x2d0/0x34c [ 31.082663] register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] really_probe+0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207] device_initial_probe+0x14/0x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451] process_one_work+0x3ac/0x988 [ 31.084643] worker_thread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] ret_from_fork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90 [ 31.085157] hardirqs last disabled at (64549): [<ffffffc081adf010>] _raw_spin_lock_irqsave+0xc0/0xdc [ 31.085277] softirqs last enabled at (64503): [<ffffffc08001071c>] __do_softirq+0x47c/0x500 [ 31.085390] softirqs last disabled at (64498): [<ffffffc080017134>] ____do_softirq+0x10/0x1c [ 31.085501] ---[ end trace 0000000000000000 ]---
--- drivers/dma/xilinx/xilinx_dpdma.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
drivers/dma/xilinx/xilinx_dpdma.c +10 -3
@@ -213,7 +213,8 @@ struct xilinx_dpdma_tx_desc {* @running: true if the channel is running * @first_frame: flag for the first frame of stream * @video_group: flag if multi-channel operation is needed for video channels -* @lock: lock to access struct xilinx_dpdma_chan +* @lock: lock to access struct xilinx_dpdma_chan. Must be taken before +* @vchan.lock, if both are to be held. * @desc_pool: descriptor allocation pool * @err_task: error IRQ bottom half handler * @desc: References to descriptors being processed
@@ -1096,12 +1097,14 @@ static void xilinx_dpdma_chan_vsync_irq(struct xilinx_dpdma_chan *chan)* Complete the active descriptor, if any, promote the pending * descriptor to active, and queue the next transfer, if any. */ +spin_lock (&chan->vchan.lock);if (chan->desc.active)vchan_cookie_complete (&chan->desc.active->vdesc); chan->desc.active = pending; chan->desc.pending =NULL ;xilinx_dpdma_chan_queue_transfer (chan); +spin_unlock (&chan->vchan.lock); out:spin_unlock_irqrestore (&chan->lock, flags);
@@ -1263,10 +1266,12 @@ static void xilinx_dpdma_issue_pending(struct dma_chan *dchan)struct xilinx_dpdma_chan *chan =to_xilinx_chan (dchan);unsigned long flags; -spin_lock_irqsave (&chan->vchan.lock, flags); +spin_lock_irqsave (&chan->lock, flags); +spin_lock (&chan->vchan.lock);if (vchan_issue_pending (&chan->vchan))xilinx_dpdma_chan_queue_transfer (chan); -spin_unlock_irqrestore (&chan->vchan.lock, flags); +spin_unlock (&chan->vchan.lock); +spin_unlock_irqrestore (&chan->lock, flags); } static int xilinx_dpdma_config(struct dma_chan *dchan,
@@ -1490,7 +1495,9 @@ static void xilinx_dpdma_chan_err_task(struct tasklet_struct *t) XILINX_DPDMA_EINTR_CHAN_ERR_MASK << chan->id);spin_lock_irqsave (&chan->lock, flags); +spin_lock (&chan->vchan.lock);xilinx_dpdma_chan_queue_transfer (chan); +spin_unlock (&chan->vchan.lock);spin_unlock_irqrestore (&chan->lock, flags); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 72/80 dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fenghua Yu <[email protected]>
[ Upstream commit f221033f5c24659dc6ad7e5cf18fb1b075f4a8be ]
During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops:
BUG: unable to handle page fault for address: 000000000002a2b8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 1470e1067 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
RIP: 0010:mutex_lock+0x2e/0x50
...
Call Trace:
<TASK>
__die+0x24/0x70
page_fault_oops+0x82/0x160
do_user_addr_fault+0x65/0x6b0
__pfx___rdmsr_safe_on_cpu+0x10/0x10
exc_page_fault+0x7d/0x170
asm_exc_page_fault+0x26/0x30
mutex_lock+0x2e/0x50
mutex_lock+0x1e/0x50
perf_pmu_migrate_context+0x87/0x1f0
perf_event_cpu_offline+0x76/0x90 [idxd]
cpuhp_invoke_callback+0xa2/0x4f0
__pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
cpuhp_thread_fun+0x98/0x150
smpboot_thread_fn+0x27/0x260
smpboot_thread_fn+0x1af/0x260
__pfx_smpboot_thread_fn+0x10/0x10
kthread+0x103/0x140
__pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x50
__pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
<TASK>Fix the issue by preventing the migration of the perf context to an invalid target.
--- drivers/dma/idxd/perfmon.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
drivers/dma/idxd/perfmon.c +3 -6
@@ -529,14 +529,11 @@ static int perf_event_cpu_offline(unsigned int cpu, struct hlist_node *node)return 0 ; target =cpumask_any_but (cpu_online_mask, cpu); -/* migrate events if there is a valid target */ -if (target < nr_cpu_ids) +if (target < nr_cpu_ids) {cpumask_set_cpu (target, &perfmon_dsa_cpu_mask); -else - target =-1 ; - -perf_pmu_migrate_context (&idxd_pmu->pmu, cpu, target); +perf_pmu_migrate_context (&idxd_pmu->pmu, cpu, target); + }return 0 ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 73/80 riscv: fix VMALLOC_START definition
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baoquan He <[email protected]>
[ Upstream commit ac88ff6b9d7dea9f0907c86bdae204dde7d5c0e6 ]
When below config items are set, compiler complained:
--------------------CONFIG_CRASH_CORE=yCONFIG_KEXEC_CORE=yCONFIG_CRASH_DUMP=y
......
-----------------------
-------------------------------------------------------------------arch/riscv/kernel/crash_core.c: In function 'arch_crash_save_vmcoreinfo':arch/riscv/kernel/crash_core.c:11:58: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'int' [-Wformat=]
11 | vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
| ~~^
| |
| long unsigned int
| %x----------------------------------------------------------------------
This is because on riscv macro VMALLOC_START has different type when CONFIG_MMU is set or unset.
arch/riscv/include/asm/pgtable.h:
--------------------------------------------------
Changing it to _AC(0, UL) in case CONFIG_MMU=n can fix the warning.
Stable-dep-of: 6065e736f82c ("riscv: Fix TASK_SIZE on 64-bit NOMMU")
--- arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/pgtable.h +1 -1
@@ -676,7 +676,7 @@ static inline pmd_t pmdp_establish(struct vm_area_struct *vma,#define PAGE_KERNEL __pgprot(0)#define swapper_pg_dir NULL#define TASK_SIZE 0xffffffffUL -#define VMALLOC_START 0 +#define VMALLOC_START _AC(0, UL)#define VMALLOC_END TASK_SIZE#endif /* !CONFIG_MMU */
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 74/80 riscv: Fix TASK_SIZE on 64-bit NOMMU
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Samuel Holland <[email protected]>
[ Upstream commit 6065e736f82c817c9a597a31ee67f0ce4628e948 ]
On NOMMU, userspace memory can come from anywhere in physical RAM. The current definition of TASK_SIZE is wrong if any RAM exists above 4G, causing spurious failures in the userspace access routines.
--- arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/pgtable.h +1 -1
@@ -675,7 +675,7 @@ static inline pmd_t pmdp_establish(struct vm_area_struct *vma,#define PAGE_SHARED __pgprot(0)#define PAGE_KERNEL __pgprot(0)#define swapper_pg_dir NULL -#define TASK_SIZE 0xffffffffUL +#define TASK_SIZE _AC(-1, UL)#define VMALLOC_START _AC(0, UL)#define VMALLOC_END TASK_SIZE
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 75/80 i2c: smbus: fix NULL function pointer dereference
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wolfram Sang <[email protected]>
[ Upstream commit 91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f ]
Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer.
--- drivers/i2c/i2c-core-base.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/i2c/i2c-core-base.c +6 -6
@@ -2072,13 +2072,18 @@ static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg *msgs,* Returns negative errno, else the number of messages executed. * * Adapter lock must be held when calling this function. No debug logging -* takes place. adap->algo->master_xfer existence isn't checked. +* takes place. */ int __i2c_transfer (struct i2c_adapter *adap,struct i2c_msg *msgs,int num) {unsigned long orig_jiffies;int ret, try; +if (!adap->algo->master_xfer) { +dev_dbg (&adap->dev,"I2C level transfers not supported\n" ); +return -EOPNOTSUPP ; + } +if (WARN_ON (!msgs || num <1 ))return -EINVAL ;
@@ -2145,11 +2150,6 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) {int ret; -if (!adap->algo->master_xfer) { -dev_dbg (&adap->dev,"I2C level transfers not supported\n" ); -return -EOPNOTSUPP ; - } -/* REVISIT the fault reporting model here is weak: * * - When we get an error after receiving N bytes from a slave,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 76/80 fbdev: fix incorrect address computation in deferred IO
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nam Cao <[email protected]>
commit 78d9161d2bcd442d93d917339297ffa057dbee8c upstream.
With deferred IO enabled, a page fault happens when data is written to the framebuffer device. Then driver determines which page is being updated by calculating the offset of the written virtual address within the virtual memory area, and uses this offset to get the updated page within the internal buffer. This page is later copied to hardware (thus the name "deferred IO").
This offset calculation is only correct if the virtual memory area is mapped to the beginning of the internal buffer. Otherwise this is wrong. For example, if users do:
mmap(ptr, 4096, PROT_WRITE, MAP_FIXED | MAP_SHARED, fd, 0xff000);
Then the virtual memory area will mapped at offset 0xff000 within the internal buffer. This offset 0xff000 is not accounted for, and wrong page is updated.
Correct the calculation by using vmf->pgoff instead. With this change, the variable "offset" will no longer hold the exact offset value, but it is rounded down to multiples of PAGE_SIZE. But this is still correct, because this variable is only used to calculate the page offset.
--- drivers/video/fbdev/core/fb_defio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/fbdev/core/fb_defio.c +1 -1
@@ -149,7 +149,7 @@ static vm_fault_t fb_deferred_io_mkwriteunsigned long offset;vm_fault_t ret; - offset = (vmf->address - vmf->vma->vm_start); + offset = vmf->pgoff <<PAGE_SHIFT ;/* this is a callback we get when userspace first tries to write to the page. we schedule a workqueue. that workqueue
Re: [PATCH 5.15 76/80] fbdev: fix incorrect address computation in deferred IO
Hi Greg,
Quoted 29 lines · Greg Kroah-Hartman
5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nam Cao <[email protected]>
commit
78d9161d2bcd442d93d917339297ffa057dbee8cupstream.With deferred IO enabled, a page fault happens when data is written to the framebuffer device. Then driver determines which page is being updated by calculating the offset of the written virtual address within the virtual memory area, and uses this offset to get the updated page within the internal buffer. This page is later copied to hardware (thus the name "deferred IO").
This offset calculation is only correct if the virtual memory area is mapped to the beginning of the internal buffer. Otherwise this is wrong. For example, if users do:
mmap(ptr, 4096, PROT_WRITE, MAP_FIXED | MAP_SHARED, fd, 0xff000);Then the virtual memory area will mapped at offset
0xff000within the internal buffer. This offset0xff000is not accounted for, and wrong page is updated.Correct the calculation by using
vmf->pgoffinstead. With this change, the variable "offset" will no longer hold the exact offset value, but it is rounded down to multiples ofPAGE_SIZE. But this is still correct, because this variable is only used to calculate the page offset.
Quoted 10 lines
Reported-by Harshit Mogalapalli <[email protected]>Fixes 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")Cc <[email protected]>Signed-off-by Nam Cao <[email protected]>Reviewed-by Thomas Zimmermann <[email protected]>Tested-by Harshit Mogalapalli <[email protected]>Signed-off-by Thomas Zimmermann <[email protected]>[rebase to v5.15]
FYI,
The reproducer doesnot create task hung messages anymore. This was initially reported when we first saw regression after fbdev commits in 5.15.149 update: https://lore.kernel.org/all/[email protected]/
Regression is fixed after this patch in 5.15.158
Thanks to Nam for quick 5.15.y backport and for helping with the fix.
Thanks,
Harshit
Quoted 20 lines
Signed-off-by Nam Cao <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/video/fbdev/core/fb_defio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/video/fbdev/core/fb_defio.c +1
-1@@ -149,7 +149,7 @@ static vm_fault_t fb_deferred_io_mkwriteunsigned long offset;vm_fault_t ret; - offset = (vmf->address - vmf->vma->vm_start); + offset = vmf->pgoff <<PAGE_SHIFT ;/* this is a callback we get when userspace first tries to write to the page. we schedule a workqueue. that workqueue
Greg Kroah-Hartman
maintainerPATCH 77/80 HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nam Cao <[email protected]>
commit 9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e upstream.
The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that.
More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop.
Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up.
Delete this unnecessary flag.
--- drivers/hid/i2c-hid/i2c-hid-core.c | 8 -------- 1 file changed, 8 deletions(-)
drivers/hid/i2c-hid/i2c-hid-core.c +0 -8
@@ -51,7 +51,6 @@/* flags */ #define I2C_HID_STARTED 0#define I2C_HID_RESET_PENDING 1 -#define I2C_HID_READ_PENDING 2#define I2C_HID_PWR_ON 0x00#define I2C_HID_PWR_SLEEP 0x01
@@ -251,7 +250,6 @@ static int __i2c_hid_command(struct i2c_ msg[1 ].len = data_len; msg[1 ].buf = buf_recv; msg_num =2 ; -set_bit (I2C_HID_READ_PENDING , &ihid->flags); }if (wait)
@@ -259,9 +257,6 @@ static int __i2c_hid_command(struct i2c_ ret =i2c_transfer (client->adapter, msg, msg_num); -if (data_len >0 ) -clear_bit (I2C_HID_READ_PENDING , &ihid->flags); -if (ret != msg_num)return ret <0 ? ret : -EIO ;
@@ -533,9 +528,6 @@ static irqreturn_t i2c_hid_irq(int irq, {struct i2c_hid *ihid = dev_id; -if (test_bit (I2C_HID_READ_PENDING , &ihid->flags)) -return IRQ_HANDLED ; -i2c_hid_get_input (ihid);return IRQ_HANDLED ;
Greg Kroah-Hartman
maintainerPATCH 78/80 bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Wilcox (Oracle) <[email protected]>
commit 5af385f5f4cddf908f663974847a4083b2ff2c79 upstream.
bits_per() rounds up to the next power of two when passed a power of two. This causes crashes on some machines and configurations.
--- kernel/bounds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/bounds.c +1 -1
@@ -19,7 +19,7 @@ int main(void)DEFINE (NR_PAGEFLAGS , __NR_PAGEFLAGS);DEFINE (MAX_NR_ZONES , __MAX_NR_ZONES);#ifdef CONFIG_SMP -DEFINE (NR_CPUS_BITS ,bits_per (CONFIG_NR_CPUS )); +DEFINE (NR_CPUS_BITS ,order_base_2 (CONFIG_NR_CPUS ));#endif DEFINE (SPINLOCK_SIZE ,sizeof (spinlock_t));/* End of constants */
Greg Kroah-Hartman
maintainerPATCH 79/80 udp: preserve the connected status if only UDP cmsg
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yick Xie <[email protected]>
commit 680d11f6e5427b6af1321932286722d24a8b16c1 upstream.
If "udp_cmsg_send()" returned 0 (i.e. only UDP cmsg), "connected" should not be set to 0. Otherwise it stops the connected socket from using the cached route.
--- net/ipv4/udp.c | 5 +++-- net/ipv6/udp.c | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-)
net/ipv4/udp.c +3 -2
@@ -1139,16 +1139,17 @@ int udp_sendmsg(struct sock *sk, structif (msg->msg_controllen) { err =udp_cmsg_send (sk, msg, &ipc.gso_size); -if (err >0 ) +if (err >0 ) { err =ip_cmsg_send (sk, msg, &ipc, sk->sk_family ==AF_INET6 ); + connected =0 ; + }if (unlikely (err <0 )) {kfree (ipc.opt);return err; }if (ipc.opt) free =1 ; - connected =0 ; }if (!ipc.opt) {struct ip_options_rcu *inet_opt;
net/ipv6/udp.c +3 -2
@@ -1479,9 +1479,11 @@ do_udp_sendmsg: ipc6.opt = opt; err =udp_cmsg_send (sk, msg, &ipc6.gso_size); -if (err >0 ) +if (err >0 ) { err =ip6_datagram_send_ctl (sock_net (sk), sk, msg, &fl6, &ipc6); + connected = false; + }if (err <0 ) {fl6_sock_release (flowlabel);return err;
@@ -1493,7 +1495,6 @@ do_udp_sendmsg: }if (!(opt->opt_nflen|opt->opt_flen)) opt =NULL ; - connected = false; }if (!opt) { opt =txopt_get (np);
Greg Kroah-Hartman
maintainerPATCH 80/80 serial: core: fix kernel-doc for uart_port_unlock_irqrestore()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Randy Dunlap <[email protected]>
commit 29bff582b74ed0bdb7e6986482ad9e6799ea4d2f upstream.
Fix the function name to avoid a kernel-doc warning:
include/linux/serial_core.h:666: warning: expecting prototype for uart_port_lock_irqrestore(). Prototype was for uart_port_unlock_irqrestore() instead
--- include/linux/serial_core.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/serial_core.h +1 -1
@@ -330,7 +330,7 @@ static inline void uart_port_unlock_irq( }/** -* uart_port_lock_irqrestore - Unlock the UART port, restore interrupts +* uart_port_unlock_irqrestore - Unlock the UART port, restore interrupts * @up: Pointer to UART port structure * @flags: The saved interrupt flags for restore */
Hi Greg,
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.158 release. There are 80 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 Thu, 02 May 2024 10:30:27 +0000. Anything received after that time might be too late.
No problems seen on x86_64 and aarch64 with our testing.
Thanks,
Harshit
Quoted 11 lines
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
----
Hello,
Quoted 5 lines · On Tue, 30 Apr 2024 12:39:32 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 5.15.158 release. There are 80 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.
Quoted 8 lines
Responses should be made by Thu, 02 May 2024 10:30:27 +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/v5.x/stable-review/patch-5.15.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] d6b90d569cec ("Linux 5.15.158-rc1")
Thanks,
SJ
[...]
---
ok 1 selftests: damon: debugfs_attrs.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh
ok 12 selftests: damon-tests: build_m68k.sh
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.158 release. There are 80 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 Thu, 02 May 2024 10:30:27 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.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:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.158 release. There are 80 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 Thu, 02 May 2024 10:30:27 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.158 release. There are 80 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 Thu, 02 May 2024 10:30:27 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.15.158-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: d6b90d569cec2513e2bd695321ba651a37d4267f
* git describe: v5.15.157-81-gd6b90d569cec
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.157-81-gd6b90d569cec
## Test Regressions (compared to v5.15.155)
## Metric Regressions (compared to v5.15.155)
## Test Fixes (compared to v5.15.155)
## Metric Fixes (compared to v5.15.155)
## Test result summary
total: 91343, pass: 73626, fail: 2525, skip: 15124, xfail: 68
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 103 total, 103 passed, 0 failed
* arm64: 30 total, 30 passed, 0 failed
* i386: 25 total, 25 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* parisc: 3 total, 3 passed, 0 failed
* powerpc: 24 total, 24 passed, 0 failed
* riscv: 8 total, 8 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sh: 9 total, 9 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 27 total, 27 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mm
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-smoketest
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.158 release. There are 80 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 Thu, 02 May 2024 10:30:27 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
102 tests: 102 pass, 0 failLinux version: 5.15.158-rc1-gd6b90d569cec
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-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.158 release. There are 80 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 Thu, 02 May 2024 10:30:27 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
[2024-04-30 12:39] Greg Kroah-Hartman:
Quoted 7 lines
This is the start of the stable review cycle for the 5.15.158 release. There are 80 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 Thu, 02 May 2024 10:30:27 +0000. Anything received after that time might be too late.
Hi, 5.15.158-rc1 is running fine on a Netgear GS108T v3 (the SoC is a Realtek RTL8380M, which has a MIPS 4KEc core).
Note that I have *not* tested building the kernel documentation, and I suspect that building the documentation with docutils >= 0.21 would likely fail without the patch from
https://lore.kernel.org/all/[email protected]/
Regards
Pascal