5.15.107-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 5.15.107-rc1 review
This is the start of the stable review cycle for the 5.15.107 release. There are 93 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 14 Apr 2023 08:28:02 +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.107-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.107-rc1
Alistair Popple <[email protected]>
mm: take a page reference when removing device exclusive entries
Robert Foss <[email protected]>
drm/bridge: lt9611: Fix PLL being unable to lock
Rongwei Wang <[email protected]>
mm/swap: fix swap_info_struct race between swapoff and get_swap_pages()
Zheng Yejian <[email protected]>
ring-buffer: Fix race while reader and writer are on the same page
Karol Herbst <[email protected]>
drm/nouveau/disp: Support more modes by checking with lower bpc
Boris Brezillon <[email protected]>
drm/panfrost: Fix the panfrost_mmu_map_fault_addr() error path
Yafang Shao <[email protected]>
mm: vmalloc: avoid warn_alloc noise caused by fatal signal
Jason Montleon <[email protected]>
ASoC: hdac_hdmi: use set_stream() instead of set_tdm_slots()
Steven Rostedt (Google) <[email protected]>
tracing: Free error logs of tracing instances
Michal Sojka <[email protected]>
can: isotp: isotp_ops: fix poll() to not report false EPOLLOUT events
Oleksij Rempel <[email protected]>
can: j1939: j1939_tp_tx_dat_new(): fix out-of-bounds memory access
Christian Brauner <[email protected]>
fs: drop peer group ids under namespace lock
Zheng Yejian <[email protected]>
ftrace: Fix issue that 'direct->addr' not restored in modify_ftrace_direct()
John Keeping <[email protected]>
ftrace: Mark get_lock_parent_ip() __always_inline
Kan Liang <[email protected]>
perf/core: Fix the same task check in perf_event_set_output
Thiago Rafael Becker <[email protected]>
cifs: sanitize paths in cifs_update_super_prepath.
Steve French <[email protected]>
smb3: lower default deferred close timeout to address perf regression
Steve French <[email protected]>
smb3: allow deferred close timeout to be configurable
Zhong Jinghua <[email protected]>
scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param()
Li Zetao <[email protected]>
scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()
Nuno Sá <[email protected]>
iio: adc: ad7791: fix IRQ flags
Steve Clevenger <[email protected]>
coresight-etm4: Fix for() loop drvdata->nr_addr_cmp range bug
Suzuki K Poulose <[email protected]>
coresight: etm4x: Do not access TRCIDR1 for identification
Jeremy Soller <[email protected]>
ALSA: hda/realtek: Add quirk for Clevo X370SNW
Marios Makassikis <[email protected]>
ksmbd: do not call kvmalloc() with __GFP_NORETRY | __GFP_NO_WARN
Geert Uytterhoeven <[email protected]>
dt-bindings: serial: renesas,scif: Fix 4th IRQ for 4-IRQ SCIFs
Ryusuke Konishi <[email protected]>
nilfs2: fix sysfs interface lifetime
Ryusuke Konishi <[email protected]>
nilfs2: fix potential UAF of struct nilfs_sc_info in nilfs_segctor_thread()
Sherry Sun <[email protected]>
tty: serial: fsl_lpuart: avoid checking for transfer complete when UARTCTRL_SBK is asserted in lpuart32_tx_empty
Biju Das <[email protected]>
tty: serial: sh-sci: Fix Rx on RZ/G2L SCI
Biju Das <[email protected]>
tty: serial: sh-sci: Fix transmit end interrupt handler
Kai-Heng Feng <[email protected]>
iio: light: cm32181: Unregister second I2C client if present
William Breathitt Gray <[email protected]>
iio: dac: cio-dac: Fix max DAC write value check for 12-bit
Lars-Peter Clausen <[email protected]>
iio: adc: ti-ads7950: Set can_sleep flag for GPIO chip
Arnd Bergmann <[email protected]>
iio: adis16480: select CONFIG_CRC32
Bjørn Mork <[email protected]>
USB: serial: option: add Quectel RM500U-CN modem
Enrico Sau <[email protected]>
USB: serial: option: add Telit FE990 compositions
RD Babiera <[email protected]>
usb: typec: altmodes/displayport: Fix configure initial pin assignment
Kees Jan Koster <[email protected]>
USB: serial: cp210x: add Silicon Labs IFS-USB-DATACABLE IDs
Heikki Krogerus <[email protected]>
usb: dwc3: pci: add support for the Intel Meteor Lake-S
Pawel Laszczak <[email protected]>
usb: cdnsp: Fixes error: uninitialized symbol 'len'
D Scott Phillips <[email protected]>
xhci: also avoid the XHCI_ZERO_64B_REGS quirk with a passthrough iommu
Wayne Chang <[email protected]>
usb: xhci: tegra: fix sleep in atomic call
Masahiro Yamada <[email protected]>
kbuild: refactor single builds of *.ko
Shailend Chand <[email protected]>
gve: Secure enough bytes in the first TX desc for all TCP pkts
Andy Roulin <[email protected]>
ethtool: reset #lanes when lanes is omitted
Lingyu Liu <[email protected]>
ice: Reset FDIR counter in FDIR init stage
Simei Su <[email protected]>
ice: fix wrong fallback logic for FDIR
Dai Ngo <[email protected]>
NFSD: callback request does not use correct credential for AUTH_SYS
Jeff Layton <[email protected]>
sunrpc: only free unix grouplist after RCU settles
Corinna Vinschen <[email protected]>
net: stmmac: fix up RX flow hash indirection table when setting channels
Siddharth Vadapalli <[email protected]>
net: ethernet: ti: am65-cpsw: Fix mdio cleanup in probe
Dhruva Gole <[email protected]>
gpio: davinci: Add irq chip flag to skip set wake
Mark Pearson <[email protected]>
platform/x86: think-lmi: Clean up display of current_value on Thinkstation
Mark Pearson <[email protected]>
platform/x86: think-lmi: Fix memory leaks when parsing ThinkStation WMI strings
Armin Wolf <[email protected]>
platform/x86: think-lmi: Fix memory leak when showing current settings
Ziyang Xuan <[email protected]>
ipv6: Fix an uninit variable access bug in __ip6_make_skb()
Sricharan Ramabadhran <[email protected]>
net: qrtr: Do not do DEL_SERVER broadcast after DEL_CLIENT
Xin Long <[email protected]>
sctp: check send stream number after wait_for_sndbuf
Gustav Ekelund <[email protected]>
net: dsa: mv88e6xxx: Reset mv88e6393x force WD event bit
Jakub Kicinski <[email protected]>
net: don't let netpoll invoke NAPI if in xmit context
Eric Dumazet <[email protected]>
icmp: guard against too small mtu
Chuck Lever <[email protected]>
NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL
Ziyang Xuan <[email protected]>
net: qrtr: Fix a refcount bug in qrtr_recvmsg()
Luca Weiss <[email protected]>
net: qrtr: combine nameservice into main module
Felix Fietkau <[email protected]>
wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta
Nico Boehr <[email protected]>
KVM: s390: pv: fix external interruption loop not always detected
Uwe Kleine-König <[email protected]>
pwm: sprd: Explicitly set .polarity in .get_state()
Uwe Kleine-König <[email protected]>
pwm: cros-ec: Explicitly set .polarity in .get_state()
Mohammed Gamal <[email protected]>
Drivers: vmbus: Check for channel allocation before looking up relids
Randy Dunlap <[email protected]>
gpio: GPIO_REGMAP: select REGMAP instead of depending on it
Tonghao Zhang <[email protected]>
bpf: hash map, avoid deadlock with suitable hash mask
Christian König <[email protected]>
drm/amdgpu: fix amdgpu_job_free_resources v2
Andrey Grodzovsky <[email protected]>
drm/amdgpu: Prevent race between late signaled fences and GPU reset.
Matthew Howell <[email protected]>
serial: exar: Add support for Sealevel 7xxxC serial cards
Andy Shevchenko <[email protected]>
serial: 8250_exar: derive nr_ports from PCI ID for Acces I/O cards
Daniil Tatianin <[email protected]>
iavf/iavf_main: actually log ->src mask when talking about it
Jacob Keller <[email protected]>
iavf: return errno code instead of status code
Hans de Goede <[email protected]>
platform/x86: int3472/discrete: Ensure the clk/power enable pins are in output mode
Hans de Goede <[email protected]>
platform/x86: int3472: Split into 2 drivers
Mustafa Ismail <[email protected]>
RDMA/irdma: Do not request 2-level PBLEs for CQ alloc
Brian Foster <[email protected]>
NFSD: pass range end to vfs_fsync_range() instead of count
Chuck Lever <[email protected]>
NFSD: Fix sparse warning
Li Zetao <[email protected]>
ocfs2: fix memory leak in ocfs2_mount_volume()
Heming Zhao via Ocfs2-devel <[email protected]>
ocfs2: rewrite error handling of ocfs2_fill_super
Heming Zhao via Ocfs2-devel <[email protected]>
ocfs2: ocfs2_mount_volume does cleanup job before return error
Yang Yingliang <[email protected]>
soc: sifive: ccache: fix missing of_node_put() in sifive_ccache_init()
Yang Yingliang <[email protected]>
soc: sifive: ccache: fix missing free_irq() in error path in sifive_ccache_init()
Yang Yingliang <[email protected]>
soc: sifive: ccache: fix missing iounmap() in error path in sifive_ccache_init()
Ben Dooks <[email protected]>
soc: sifive: ccache: use pr_fmt() to remove CCACHE: prefixes
Ben Dooks <[email protected]>
soc: sifive: ccache: reduce printing on init
Zong Li <[email protected]>
soc: sifive: ccache: determine the cache level from dts
Greentime Hu <[email protected]>
soc: sifive: ccache: Rename SiFive L2 cache to Composable cache.
-------------
Diffstat:
.../devicetree/bindings/serial/renesas,scif.yaml | 4 +-
Makefile | 20 +-
arch/s390/kvm/intercept.c | 32 ++-
drivers/edac/Kconfig | 2 +-
drivers/edac/sifive_edac.c | 12 +-
drivers/gpio/Kconfig | 2 +-
drivers/gpio/gpio-davinci.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 18 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
drivers/gpu/drm/bridge/lontium-lt9611.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/disp.c | 32 +++
drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 +
drivers/hv/connection.c | 4 +
drivers/hwtracing/coresight/coresight-etm4x-core.c | 24 +-
drivers/hwtracing/coresight/coresight-etm4x.h | 20 +-
drivers/iio/adc/ad7791.c | 2 +-
drivers/iio/adc/ti-ads7950.c | 1 +
drivers/iio/dac/cio-dac.c | 4 +-
drivers/iio/imu/Kconfig | 1 +
drivers/iio/light/cm32181.c | 12 +
drivers/infiniband/hw/irdma/verbs.c | 15 +-
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
drivers/net/dsa/mv88e6xxx/global2.c | 20 ++
drivers/net/dsa/mv88e6xxx/global2.h | 1 +
drivers/net/ethernet/google/gve/gve.h | 2 +
drivers/net/ethernet/google/gve/gve_tx.c | 12 +-
drivers/net/ethernet/intel/iavf/iavf_main.c | 22 +-
drivers/net/ethernet/intel/ice/ice_virtchnl_fdir.c | 23 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +-
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 6 +-
drivers/platform/x86/intel/int3472/Makefile | 9 +-
...472_clk_and_regulator.c => clk_and_regulator.c} | 5 +-
drivers/platform/x86/intel/int3472/common.c | 54 +++++
.../{intel_skl_int3472_common.h => common.h} | 3 -
.../{intel_skl_int3472_discrete.c => discrete.c} | 32 ++-
.../x86/intel/int3472/intel_skl_int3472_common.c | 106 --------
.../{intel_skl_int3472_tps68470.c => tps68470.c} | 23 +-
drivers/platform/x86/think-lmi.c | 20 +-
drivers/pwm/pwm-cros-ec.c | 1 +
drivers/pwm/pwm-sprd.c | 1 +
drivers/scsi/iscsi_tcp.c | 3 +-
drivers/scsi/qla2xxx/qla_os.c | 1 +
drivers/soc/sifive/Kconfig | 6 +-
drivers/soc/sifive/Makefile | 2 +-
drivers/soc/sifive/sifive_ccache.c | 266 +++++++++++++++++++++
drivers/soc/sifive/sifive_l2_cache.c | 237 ------------------
drivers/tty/serial/8250/8250_exar.c | 51 ++--
drivers/tty/serial/fsl_lpuart.c | 8 +-
drivers/tty/serial/sh-sci.c | 10 +-
drivers/usb/cdns3/cdnsp-ep0.c | 3 +-
drivers/usb/dwc3/dwc3-pci.c | 4 +
drivers/usb/host/xhci-tegra.c | 6 +-
drivers/usb/host/xhci.c | 6 +-
drivers/usb/serial/cp210x.c | 1 +
drivers/usb/serial/option.c | 10 +
drivers/usb/typec/altmodes/displayport.c | 6 +-
fs/cifs/cifsfs.c | 1 +
fs/cifs/connect.c | 2 +
fs/cifs/file.c | 4 +-
fs/cifs/fs_context.c | 22 +-
fs/cifs/fs_context.h | 11 +
fs/cifs/misc.c | 2 +-
fs/ksmbd/connection.c | 5 +-
fs/namespace.c | 2 +-
fs/nfsd/nfs4callback.c | 4 +-
fs/nfsd/nfs4proc.c | 7 +-
fs/nfsd/nfs4xdr.c | 4 +-
fs/nilfs2/segment.c | 3 +-
fs/nilfs2/super.c | 2 +
fs/nilfs2/the_nilfs.c | 12 +-
fs/ocfs2/journal.c | 2 +-
fs/ocfs2/journal.h | 1 +
fs/ocfs2/super.c | 105 ++++----
include/linux/ftrace.h | 2 +-
include/soc/sifive/sifive_ccache.h | 16 ++
include/soc/sifive/sifive_l2_cache.h | 16 --
kernel/bpf/hashtab.c | 4 +-
kernel/events/core.c | 2 +-
kernel/trace/ftrace.c | 15 +-
kernel/trace/ring_buffer.c | 13 +-
kernel/trace/trace.c | 1 +
mm/memory.c | 16 +-
mm/swapfile.c | 3 +-
mm/vmalloc.c | 8 +-
net/can/isotp.c | 17 +-
net/can/j1939/transport.c | 5 +-
net/core/netpoll.c | 19 +-
net/ethtool/linkmodes.c | 7 +-
net/ipv4/icmp.c | 5 +
net/ipv6/ip6_output.c | 7 +-
net/mac80211/sta_info.c | 3 +-
net/qrtr/Makefile | 3 +-
net/qrtr/{qrtr.c => af_qrtr.c} | 2 +
net/qrtr/ns.c | 15 +-
net/sctp/socket.c | 4 +
net/sunrpc/svcauth_unix.c | 17 +-
sound/pci/hda/patch_realtek.c | 1 +
sound/soc/codecs/hdac_hdmi.c | 17 +-
101 files changed, 968 insertions(+), 639 deletions(-)Greg Kroah-Hartman
maintainerPATCH 1/93 soc: sifive: ccache: Rename SiFive L2 cache to Composable cache.
From: Greentime Hu <[email protected]>
[ Upstream commit ca120a79cf5a3323172c82e77efd70ae10d120ef ]
Since composable cache may be L3 cache if there is a L2 cache, we should use its original name composable cache to prevent confusion.
There are some new lines were generated due to adding the compatible "sifive,ccache0" into ID table and indent requirement.
The sifive L2 has been renamed to sifive CCACHE, EDAC driver needs to apply the change as well.
Stable-dep-of: 73e770f08502 ("soc: sifive: ccache: fix missing iounmap() in error path in sifive_ccache_init()")
--- drivers/edac/Kconfig | 2 +- drivers/edac/sifive_edac.c | 12 +- drivers/soc/sifive/Kconfig | 6 +- drivers/soc/sifive/Makefile | 2 +- drivers/soc/sifive/sifive_ccache.c | 245 +++++++++++++++++++++++++++ drivers/soc/sifive/sifive_l2_cache.c | 237 -------------------------- include/soc/sifive/sifive_ccache.h | 16 ++ include/soc/sifive/sifive_l2_cache.h | 16 -- 8 files changed, 272 insertions(+), 264 deletions(-) create mode 100644 drivers/soc/sifive/sifive_ccache.c delete mode 100644 drivers/soc/sifive/sifive_l2_cache.c create mode 100644 include/soc/sifive/sifive_ccache.h delete mode 100644 include/soc/sifive/sifive_l2_cache.h
drivers/edac/Kconfig +1 -1
@@ -471,7 +471,7 @@ config EDAC_ALTERA_SDMMC config EDAC_SIFIVE bool "Sifive platform EDAC driver" - depends on EDAC=y && SIFIVE_L2 + depends on EDAC=y && SIFIVE_CCACHE help Support for error detection and correction on the SiFive SoCs.
drivers/edac/sifive_edac.c +6 -6
@@ -2,7 +2,7 @@/* * SiFive Platform EDAC Driver * -* Copyright (C) 2018-2019 SiFive, Inc. +* Copyright (C) 2018-2022 SiFive, Inc. * * This driver is partially based on octeon_edac-pc.c *
@@ -10,7 +10,7 @@#include <linux/edac.h> #include <linux/platform_device.h> #include "edac_module.h" -#include <soc/sifive/sifive_l2_cache.h> +#include <soc/sifive/sifive_ccache.h> #define DRVNAME "sifive_edac"
@@ -32,9 +32,9 @@ int ecc_err_event(struct notifier_block *this, unsigned long event, void *ptr) p = container_of(this, struct sifive_edac_priv, notifier); -if (event ==SIFIVE_L2_ERR_TYPE_UE ) +if (event ==SIFIVE_CCACHE_ERR_TYPE_UE )edac_device_handle_ue (p->dci,0 ,0 , msg); -else if (event ==SIFIVE_L2_ERR_TYPE_CE ) +else if (event ==SIFIVE_CCACHE_ERR_TYPE_CE )edac_device_handle_ce (p->dci,0 ,0 , msg);return NOTIFY_OK ;
@@ -67,7 +67,7 @@ static int ecc_register(struct platform_device *pdev) goto err; } -register_sifive_l2_error_notifier (&p->notifier); +register_sifive_ccache_error_notifier (&p->notifier);return 0 ;
@@ -81,7 +81,7 @@ static int ecc_unregister(struct platform_device *pdev) {struct sifive_edac_priv *p =platform_get_drvdata (pdev); -unregister_sifive_l2_error_notifier (&p->notifier); +unregister_sifive_ccache_error_notifier (&p->notifier);edac_device_del_device (&pdev->dev);edac_device_free_ctl_info (p->dci);
drivers/soc/sifive/Kconfig +3 -3
@@ -2,9 +2,9 @@ if SOC_SIFIVE -config SIFIVE_L2 - bool "Sifive L2 Cache controller" +config SIFIVE_CCACHE + bool "Sifive Composable Cache controller" help - Support for the L2 cache controller on SiFive platforms. + Support for the composable cache controller on SiFive platforms. endif
drivers/soc/sifive/Makefile +1 -1
@@ -1,3 +1,3 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_SIFIVE_L2) += sifive_l2_cache.o +obj-$(CONFIG_SIFIVE_CCACHE) += sifive_ccache.o
drivers/soc/sifive/sifive_ccache.c new file +245 -0
245 lines not on this page · raw message
drivers/soc/sifive/sifive_l2_cache.c deleted +0 -237
237 lines not on this page · raw message
include/soc/sifive/sifive_ccache.h new file +16 -0
@@ -0,0 +1,16 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* +* SiFive Composable Cache Controller header file +* +*/ + +#ifndef __SOC_SIFIVE_CCACHE_H +#define __SOC_SIFIVE_CCACHE_H + +extern int register_sifive_ccache_error_notifier (struct notifier_block *nb); +extern int unregister_sifive_ccache_error_notifier (struct notifier_block *nb); + +#define SIFIVE_CCACHE_ERR_TYPE_CE 0 +#define SIFIVE_CCACHE_ERR_TYPE_UE 1 + +#endif /* __SOC_SIFIVE_CCACHE_H */
include/soc/sifive/sifive_l2_cache.h deleted +0 -16
@@ -1,16 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* -* SiFive L2 Cache Controller header file -* -*/ - -#ifndef __SOC_SIFIVE_L2_CACHE_H -#define __SOC_SIFIVE_L2_CACHE_H - -extern int register_sifive_l2_error_notifier (struct notifier_block *nb); -extern int unregister_sifive_l2_error_notifier (struct notifier_block *nb); - -#define SIFIVE_L2_ERR_TYPE_CE 0 -#define SIFIVE_L2_ERR_TYPE_UE 1 - -#endif /* __SOC_SIFIVE_L2_CACHE_H */
Signature · 1 line
2.39.2
Re: [PATCH 5.15 01/93] soc: sifive: ccache: Rename SiFive L2 cache to Composable cache.
Quoted 13 lines · Greg Kroah-Hartman
From: Greentime Hu <[email protected]>
[ Upstream commit
ca120a79cf5a3323172c82e77efd70ae10d120ef]Since composable cache may be L3 cache if there is a L2 cache, we should use its original name composable cache to prevent confusion.
There are some new lines were generated due to adding the compatible "sifive,ccache0" into ID table and indent requirement.
The sifive L2 has been renamed to sifive CCACHE, EDAC driver needs to apply the change as well.
Quoted 8 lines
Signed-off-by Greentime Hu <[email protected]>Signed-off-by Zong Li <[email protected]>Co-developed-by Zong Li <[email protected]>Reviewed-by Conor Dooley <[email protected]>Signed-off-by Palmer Dabbelt <[email protected]>Stable-dep-of:
73e770f08502("soc: sifive: ccache: fix missingiounmap()in error path insifive_ccache_init()")Signed-off-by Sasha Levin <[email protected]>
Did I just miss AUTOSEL emails for this stuff?
NAK. This seems waay too invasive to me, and changing the Kconfig symbol for the driver in stable kernels sounds like a bit of a nasty surprise?
The two actual fixes that this is a dep of should be backported individually, please drop patches 1-7 (inclusive) & I'll give you less invasive backports for 6 & 7.
Cheers,
Conor.
Greg Kroah-Hartman
maintainerRe: [PATCH 5.15 01/93] soc: sifive: ccache: Rename SiFive L2 cache to Composable cache.
Quoted 23 lines · Conor Dooley
Quoted 13 lines · Greg Kroah-Hartman
From: Greentime Hu <[email protected]>
[ Upstream commit
ca120a79cf5a3323172c82e77efd70ae10d120ef]Since composable cache may be L3 cache if there is a L2 cache, we should use its original name composable cache to prevent confusion.
There are some new lines were generated due to adding the compatible "sifive,ccache0" into ID table and indent requirement.
The sifive L2 has been renamed to sifive CCACHE, EDAC driver needs to apply the change as well.
Quoted 8 lines
Signed-off-by Greentime Hu <[email protected]>Signed-off-by Zong Li <[email protected]>Co-developed-by Zong Li <[email protected]>Reviewed-by Conor Dooley <[email protected]>Signed-off-by Palmer Dabbelt <[email protected]>Stable-dep-of:
73e770f08502("soc: sifive: ccache: fix missingiounmap()in error path insifive_ccache_init()")Signed-off-by Sasha Levin <[email protected]>
Quoted 1 line
Did I just miss AUTOSEL emails for this stuff?
No, there was none as it was pulled in as a dependancy.
Quoted 6 lines
NAK. This seems waay too invasive to me, and changing the
Kconfigsymbol for the driver in stable kernels sounds like a bit of a nasty surprise?The two actual fixes that this is a dep of should be backported individually, please drop patches 1-7 (inclusive) & I'll give you less invasive backports for 6 & 7.
Ok, I'll drop all 7 now, thanks.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 2/93 soc: sifive: ccache: determine the cache level from dts
In reply to Greg Kroah-HartmanFrom: Zong Li <[email protected]>
[ Upstream commit 95f196f3212bbc258611c22865aef12b98304e1d ]
Composable cache could be L2 or L3 cache, use 'cache-level' property of device node to determine the level.
Stable-dep-of: 73e770f08502 ("soc: sifive: ccache: fix missing iounmap() in error path in sifive_ccache_init()")
--- drivers/soc/sifive/sifive_ccache.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/soc/sifive/sifive_ccache.c +5 -1
@@ -38,6 +38,7 @@static void __iomem *ccache_base;static int g_irq[SIFIVE_CCACHE_MAX_ECCINTR ];static struct riscv_cacheinfo_ops ccache_cache_ops; +static int level;enum {DIR_CORR =0 ,
@@ -144,7 +145,7 @@ static const struct attribute_group *ccache_get_priv_group(struct cacheinfo *this_leaf) {/* We want to use private group for composable cache only */ -if (this_leaf->level ==2 ) +if (this_leaf->level == level)return &priv_attr_group;else return NULL ;
@@ -215,6 +216,9 @@ static int __init sifive_ccache_init(void)if (!ccache_base)return -ENOMEM ; +if (of_property_read_u32 (np,"cache-level" , &level)) +return -ENOENT ; + intr_num =of_property_count_u32_elems (np,"interrupts" );if (!intr_num) {pr_err ("CCACHE: no interrupts property\n" );
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 3/93 soc: sifive: ccache: reduce printing on init
In reply to Greg Kroah-HartmanFrom: Ben Dooks <[email protected]>
[ Upstream commit 3fb787e5bad50687a65ded7f3bb805cab70dff59 ]
The driver prints out 6 lines on startup, which can easily be redcued to two lines without losing any information.
Note, to make the types work better, uint64_t has been replaced with ULL to make the unsigned long long match the format in the print statement.
Stable-dep-of: 73e770f08502 ("soc: sifive: ccache: fix missing iounmap() in error path in sifive_ccache_init()")
--- drivers/soc/sifive/sifive_ccache.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-)
drivers/soc/sifive/sifive_ccache.c +11 -14
@@ -81,20 +81,17 @@ static void setup_sifive_debug(void)static void ccache_config_read (void ) { -u32 regval, val; - - regval =readl (ccache_base +SIFIVE_CCACHE_CONFIG ); - val = regval &0xFF ; -pr_info ("CCACHE: No. of Banks in the cache: %d\n" , val); - val = (regval &0xFF00 ) >>8 ; -pr_info ("CCACHE: No. of ways per bank: %d\n" , val); - val = (regval &0xFF0000 ) >>16 ; -pr_info ("CCACHE: Sets per bank: %llu\n" , (uint64_t )1 << val); - val = (regval &0xFF000000 ) >>24 ; -pr_info ("CCACHE: Bytes per cache block: %llu\n" , (uint64_t )1 << val); - - regval =readl (ccache_base +SIFIVE_CCACHE_WAYENABLE ); -pr_info ("CCACHE: Index of the largest way enabled: %d\n" , regval); +u32 cfg; + + cfg =readl (ccache_base +SIFIVE_CCACHE_CONFIG ); + +pr_info ("CCACHE: %u banks, %u ways, sets/bank=%llu, bytes/block=%llu\n" , + (cfg &0xff ), (cfg >>8 ) &0xff , +BIT_ULL ((cfg >>16 ) &0xff ), +BIT_ULL ((cfg >>24 ) &0xff )); + + cfg =readl (ccache_base +SIFIVE_CCACHE_WAYENABLE ); +pr_info ("CCACHE: Index of the largest way enabled: %u\n" , cfg); }static const struct of_device_id sifive_ccache_ids[] = {
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 4/93 soc: sifive: ccache: use pr_fmt() to remove CCACHE: prefixes
In reply to Greg Kroah-HartmanFrom: Ben Dooks <[email protected]>
[ Upstream commit 696ab9bda22a770d079dc3a23bac9aaa553d98f4 ]
Use the pr_fmt() macro to prefix all the output with "CCACHE:" to avoid having to write it out each time, or make a large diff when the next change comes along.
Stable-dep-of: 73e770f08502 ("soc: sifive: ccache: fix missing iounmap() in error path in sifive_ccache_init()")
--- drivers/soc/sifive/sifive_ccache.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
drivers/soc/sifive/sifive_ccache.c +10 -7
@@ -5,6 +5,9 @@* Copyright (C) 2018-2022 SiFive, Inc. * */ + +#define pr_fmt (fmt) "CCACHE: " fmt +#include <linux/debugfs.h> #include <linux/interrupt.h> #include <linux/of_irq.h>
@@ -85,13 +88,13 @@ static void ccache_config_read(void) cfg =readl (ccache_base +SIFIVE_CCACHE_CONFIG ); -pr_info ("CCACHE: %u banks, %u ways, sets/bank=%llu, bytes/block=%llu\n" , +pr_info ("%u banks, %u ways, sets/bank=%llu, bytes/block=%llu\n" , (cfg &0xff ), (cfg >>8 ) &0xff ,BIT_ULL ((cfg >>16 ) &0xff ),BIT_ULL ((cfg >>24 ) &0xff )); cfg =readl (ccache_base +SIFIVE_CCACHE_WAYENABLE ); -pr_info ("CCACHE: Index of the largest way enabled: %u\n" , cfg); +pr_info ("Index of the largest way enabled: %u\n" , cfg); }static const struct of_device_id sifive_ccache_ids[] = {
@@ -155,7 +158,7 @@ static irqreturn_t ccache_int_handler(int irq, void *device)if (irq == g_irq[DIR_CORR ]) { add_h =readl (ccache_base +SIFIVE_CCACHE_DIRECCFIX_HIGH ); add_l =readl (ccache_base +SIFIVE_CCACHE_DIRECCFIX_LOW ); -pr_err ("CCACHE: DirError @ 0x%08X.%08X\n" , add_h, add_l); +pr_err ("DirError @ 0x%08X.%08X\n" , add_h, add_l);/* Reading this register clears the DirError interrupt sig */ readl (ccache_base +SIFIVE_CCACHE_DIRECCFIX_COUNT ); atomic_notifier_call_chain(&ccache_err_chain,
@@ -175,7 +178,7 @@ static irqreturn_t ccache_int_handler(int irq, void *device)if (irq == g_irq[DATA_CORR ]) { add_h =readl (ccache_base +SIFIVE_CCACHE_DATECCFIX_HIGH ); add_l =readl (ccache_base +SIFIVE_CCACHE_DATECCFIX_LOW ); -pr_err ("CCACHE: DataError @ 0x%08X.%08X\n" , add_h, add_l); +pr_err ("DataError @ 0x%08X.%08X\n" , add_h, add_l);/* Reading this register clears the DataError interrupt sig */ readl (ccache_base +SIFIVE_CCACHE_DATECCFIX_COUNT ); atomic_notifier_call_chain(&ccache_err_chain,
@@ -185,7 +188,7 @@ static irqreturn_t ccache_int_handler(int irq, void *device)if (irq == g_irq[DATA_UNCORR ]) { add_h =readl (ccache_base +SIFIVE_CCACHE_DATECCFAIL_HIGH ); add_l =readl (ccache_base +SIFIVE_CCACHE_DATECCFAIL_LOW ); -pr_err ("CCACHE: DataFail @ 0x%08X.%08X\n" , add_h, add_l); +pr_err ("DataFail @ 0x%08X.%08X\n" , add_h, add_l);/* Reading this register clears the DataFail interrupt sig */ readl (ccache_base +SIFIVE_CCACHE_DATECCFAIL_COUNT ); atomic_notifier_call_chain(&ccache_err_chain,
@@ -218,7 +221,7 @@ static int __init sifive_ccache_init(void) intr_num =of_property_count_u32_elems (np,"interrupts" );if (!intr_num) { -pr_err ("CCACHE: no interrupts property\n" ); +pr_err ("No interrupts property\n" );return -ENODEV ; }
@@ -227,7 +230,7 @@ static int __init sifive_ccache_init(void) rc =request_irq (g_irq[i], ccache_int_handler,0 ,"ccache_ecc" ,NULL );if (rc) { -pr_err ("CCACHE: Could not request IRQ %d\n" , g_irq[i]); +pr_err ("Could not request IRQ %d\n" , g_irq[i]);return rc; } }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 5/93 soc: sifive: ccache: fix missing iounmap() in error path in sifive_ccache_init()
In reply to Greg Kroah-HartmanFrom: Yang Yingliang <[email protected]>
[ Upstream commit 73e770f085023da327dc9ffeb6cd96b0bb22d97e ]
Add missing iounmap() before return error from sifive_ccache_init().
--- drivers/soc/sifive/sifive_ccache.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/soc/sifive/sifive_ccache.c +11 -4
@@ -216,13 +216,16 @@ static int __init sifive_ccache_init(void)if (!ccache_base)return -ENOMEM ; -if (of_property_read_u32 (np,"cache-level" , &level)) -return -ENOENT ; +if (of_property_read_u32 (np,"cache-level" , &level)) { + rc = -ENOENT ; + goto err_unmap; + } intr_num =of_property_count_u32_elems (np,"interrupts" );if (!intr_num) {pr_err ("No interrupts property\n" ); -return -ENODEV ; + rc = -ENODEV ; + goto err_unmap; }for (i =0 ; i < intr_num; i++) {
@@ -231,7 +234,7 @@ static int __init sifive_ccache_init(void) NULL);if (rc) {pr_err ("Could not request IRQ %d\n" , g_irq[i]); -return rc; + goto err_unmap; } }
@@ -244,6 +247,10 @@ static int __init sifive_ccache_init(void)setup_sifive_debug ();#endif return 0 ; + +err_unmap: +iounmap (ccache_base); +return rc; }device_initcall (sifive_ccache_init);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 6/93 soc: sifive: ccache: fix missing free_irq() in error path in sifive_ccache_init()
In reply to Greg Kroah-HartmanFrom: Yang Yingliang <[email protected]>
[ Upstream commit 756344e7cb1afbb87da8705c20384dddd0dea233 ]
Add missing free_irq() before return error from sifive_ccache_init().
--- drivers/soc/sifive/sifive_ccache.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/soc/sifive/sifive_ccache.c +4 -1
@@ -234,7 +234,7 @@ static int __init sifive_ccache_init(void) NULL);if (rc) {pr_err ("Could not request IRQ %d\n" , g_irq[i]); - goto err_unmap; + goto err_free_irq; } }
@@ -248,6 +248,9 @@ static int __init sifive_ccache_init(void)#endif return 0 ; +err_free_irq: +while (--i >=0 ) +free_irq (g_irq[i],NULL ); err_unmap:iounmap (ccache_base);return rc;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 7/93 soc: sifive: ccache: fix missing of_node_put() in sifive_ccache_init()
In reply to Greg Kroah-HartmanFrom: Yang Yingliang <[email protected]>
[ Upstream commit 8fbf94fea0b4e187ca9100936c5429f96b8a4e44 ]
The device_node pointer returned by of_find_matching_node() with refcount incremented, when finish using it, the refcount need be decreased.
--- drivers/soc/sifive/sifive_ccache.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/soc/sifive/sifive_ccache.c +11 -4
@@ -209,12 +209,16 @@ static int __init sifive_ccache_init(void)if (!np)return -ENODEV ; -if (of_address_to_resource (np,0 , &res)) -return -ENODEV ; +if (of_address_to_resource (np,0 , &res)) { + rc = -ENODEV ; + goto err_node_put; + } ccache_base =ioremap (res.start,resource_size (&res)); -if (!ccache_base) -return -ENOMEM ; +if (!ccache_base) { + rc = -ENOMEM ; + goto err_node_put; + }if (of_property_read_u32 (np,"cache-level" , &level)) { rc = -ENOENT ;
@@ -237,6 +241,7 @@ static int __init sifive_ccache_init(void) goto err_free_irq; } } +of_node_put (np);ccache_config_read ();
@@ -253,6 +258,8 @@ static int __init sifive_ccache_init(void)free_irq (g_irq[i],NULL ); err_unmap:iounmap (ccache_base); +err_node_put: +of_node_put (np);return rc; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 8/93 ocfs2: ocfs2_mount_volume does cleanup job before return error
In reply to Greg Kroah-HartmanFrom: Heming Zhao via Ocfs2-devel <[email protected]>
[ Upstream commit 0737e01de9c411e4db87dcedf4a9789d41b1c5c1 ]
After this patch, when error, ocfs2_fill_super doesn't take care to release resources which are allocated in ocfs2_mount_volume.
Stable-dep-of: ce2fcf1516d6 ("ocfs2: fix memory leak in ocfs2_mount_volume()")
--- fs/ocfs2/super.c | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-)
fs/ocfs2/super.c +23 -12
@@ -1783,11 +1783,10 @@ static int ocfs2_get_sector(struct super_block *sb,static int ocfs2_mount_volume (struct super_block *sb) {int status =0 ; -int unlock_super =0 ;struct ocfs2_super *osb =OCFS2_SB (sb);if (ocfs2_is_hard_readonly (osb)) - goto leave; + goto out;mutex_init (&osb->obs_trim_fs_mutex);
@@ -1797,44 +1796,56 @@ static int ocfs2_mount_volume(struct super_block *sb)if (status == -EBADR &&ocfs2_userspace_stack (osb))mlog (ML_ERROR ,"couldn't mount because cluster name on" " disk does not match the running cluster name.\n" ); - goto leave; + goto out; } status =ocfs2_super_lock (osb,1 );if (status <0 ) {mlog_errno (status); - goto leave; + goto out_dlm; } - unlock_super =1 ;/* This will load up the node map and add ourselves to it. */ status =ocfs2_find_slot (osb);if (status <0 ) {mlog_errno (status); - goto leave; + goto out_super_lock; }/* load all node-local system inodes */ status =ocfs2_init_local_system_inodes (osb);if (status <0 ) {mlog_errno (status); - goto leave; + goto out_super_lock; } status =ocfs2_check_volume (osb);if (status <0 ) {mlog_errno (status); - goto leave; + goto out_system_inodes; } status =ocfs2_truncate_log_init (osb); -if (status <0 ) +if (status <0 ) {mlog_errno (status); + goto out_system_inodes; + } -leave: -if (unlock_super) -ocfs2_super_unlock (osb,1 ); +ocfs2_super_unlock (osb,1 ); +return 0 ; +out_system_inodes: +if (osb->local_alloc_state ==OCFS2_LA_ENABLED ) +ocfs2_shutdown_local_alloc (osb); +ocfs2_release_system_inodes (osb); +/* before journal shutdown, we should release slot_info */ +ocfs2_free_slot_info (osb); +ocfs2_journal_shutdown (osb); +out_super_lock: +ocfs2_super_unlock (osb,1 ); +out_dlm: +ocfs2_dlm_shutdown (osb,0 ); +out:return status; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 9/93 ocfs2: rewrite error handling of ocfs2_fill_super
In reply to Greg Kroah-HartmanFrom: Heming Zhao via Ocfs2-devel <[email protected]>
[ Upstream commit f1e75d128b46e3b066e7b2e7cfca10491109d44d ]
Current ocfs2_fill_super() uses one goto label "read_super_error" to handle all error cases. And with previous serial patches, the error handling should fork more branches to handle different error cases. This patch rewrite the error handling of ocfs2_fill_super.
Stable-dep-of: ce2fcf1516d6 ("ocfs2: fix memory leak in ocfs2_mount_volume()")
--- fs/ocfs2/super.c | 67 +++++++++++++++++++++++------------------------- 1 file changed, 32 insertions(+), 35 deletions(-)
fs/ocfs2/super.c +32 -35
@@ -980,28 +980,27 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent)if (!ocfs2_parse_options (sb, data, &parsed_options,0 )) { status = -EINVAL ; - goto read_super_error; + goto out; }/* probe for superblock */ status =ocfs2_sb_probe (sb, &bh, §or_size, &stats);if (status <0 ) {mlog (ML_ERROR ,"superblock probe failed!\n" ); - goto read_super_error; + goto out; } status =ocfs2_initialize_super (sb, bh, sector_size, &stats); - osb =OCFS2_SB (sb); -if (status <0 ) { -mlog_errno (status); - goto read_super_error; - }brelse (bh); bh =NULL ; +if (status <0 ) + goto out; + + osb =OCFS2_SB (sb);if (!ocfs2_check_set_options (sb, &parsed_options)) { status = -EINVAL ; - goto read_super_error; + goto out_super; } osb->s_mount_opt = parsed_options.mount_opt; osb->s_atime_quantum = parsed_options.atime_quantum;
@@ -1018,7 +1017,7 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent) status =ocfs2_verify_userspace_stack (osb, &parsed_options);if (status) - goto read_super_error; + goto out_super; sb->s_magic =OCFS2_SUPER_MAGIC ;
@@ -1032,7 +1031,7 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent) status = -EACCES ;mlog (ML_ERROR ,"Readonly device detected but readonly " "mount was not specified.\n" ); - goto read_super_error; + goto out_super; }/* You should not be able to start a local heartbeat
@@ -1041,7 +1040,7 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent) status = -EROFS ;mlog (ML_ERROR ,"Local heartbeat specified on readonly " "device.\n" ); - goto read_super_error; + goto out_super; } status =ocfs2_check_journals_nolocks (osb);
@@ -1050,9 +1049,7 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent)mlog (ML_ERROR ,"Recovery required on readonly " "file system, but write access is " "unavailable.\n" ); - else -mlog_errno (status ); - goto read_super_error; + goto out_super; }ocfs2_set_ro_flag (osb,1 );
@@ -1068,10 +1065,8 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent) } status =ocfs2_verify_heartbeat (osb); -if (status <0 ) { -mlog_errno (status); - goto read_super_error; - } +if (status <0 ) + goto out_super; osb->osb_debug_root =debugfs_create_dir (osb->uuid_str, ocfs2_debugfs_root);
@@ -1085,15 +1080,14 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent) status =ocfs2_mount_volume (sb);if (status <0 ) - goto read_super_error; + goto out_debugfs;if (osb->root_inode) inode =igrab (osb->root_inode);if (!inode) { status = -EIO ; -mlog_errno (status); - goto read_super_error; + goto out_dismount; } osb->osb_dev_kset = kset_create_and_add(sb->s_id, NULL,
@@ -1101,7 +1095,7 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent)if (!osb->osb_dev_kset) { status = -ENOMEM ;mlog (ML_ERROR ,"Unable to create device kset %s.\n" , sb->s_id); - goto read_super_error; + goto out_dismount; }/* Create filecheck sysfs related directories/files at
@@ -1110,14 +1104,13 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent) status = -ENOMEM ;mlog (ML_ERROR ,"Unable to create filecheck sysfs directory at " "/sys/fs/ocfs2/%s/filecheck.\n" , sb->s_id); - goto read_super_error; + goto out_dismount; } root =d_make_root (inode);if (!root) { status = -ENOMEM ; -mlog_errno (status); - goto read_super_error; + goto out_dismount; } sb->s_root = root;
@@ -1164,17 +1157,21 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent)return status; -read_super_error: -brelse (bh); - -if (status) -mlog_errno (status); +out_dismount: +atomic_set (&osb->vol_state,VOLUME_DISABLED ); +wake_up (&osb->osb_mount_event); +ocfs2_dismount_volume (sb,1 ); + goto out; -if (osb) { -atomic_set (&osb->vol_state,VOLUME_DISABLED ); -wake_up (&osb->osb_mount_event); -ocfs2_dismount_volume (sb,1 ); - } +out_debugfs: +debugfs_remove_recursive (osb->osb_debug_root); +out_super: +ocfs2_release_system_inodes (osb); +kfree (osb->recovery_map); +ocfs2_delete_osb (osb); +kfree (osb); +out: +mlog_errno (status);return status; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 10/93 ocfs2: fix memory leak in ocfs2_mount_volume()
In reply to Greg Kroah-HartmanFrom: Li Zetao <[email protected]>
[ Upstream commit ce2fcf1516d674a174d9b34d1e1024d64de9fba3 ]
There is a memory leak reported by kmemleak:
unreferenced object 0xffff88810cc65e60 (size 32):
comm "mount.ocfs2", pid 23753, jiffies 4302528942 (age 34735.105s)
hex dump (first 32 bytes):
10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8170f73d>] __kmalloc+0x4d/0x150
[<ffffffffa0ac3f51>] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2]
[<ffffffffa0b65165>] ocfs2_check_volume+0x485/0x900 [ocfs2]
[<ffffffffa0b68129>] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2]
[<ffffffffa0b7160b>] ocfs2_fill_super+0xe0b/0x1740 [ocfs2]
[<ffffffff818e1fe2>] mount_bdev+0x312/0x400
[<ffffffff819a086d>] legacy_get_tree+0xed/0x1d0
[<ffffffff818de82d>] vfs_get_tree+0x7d/0x230
[<ffffffff81957f92>] path_mount+0xd62/0x1760
[<ffffffff81958a5a>] do_mount+0xca/0xe0
[<ffffffff81958d3c>] __x64_sys_mount+0x12c/0x1a0
[<ffffffff82f26f15>] do_syscall_64+0x35/0x80
[<ffffffff8300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0This call stack is related to two problems. Firstly, the ocfs2 super uses "replay_map" to trace online/offline slots, in order to recover offline slots during recovery and mount. But when ocfs2_truncate_log_init() returns an error in ocfs2_mount_volume(), the memory of "replay_map" will not be freed in error handling path. Secondly, the memory of "replay_map" will not be freed if d_make_root() returns an error in ocfs2_fill_super(). But the memory of "replay_map" will be freed normally when completing recovery and mount in ocfs2_complete_mount_recovery().
Fix the first problem by adding error handling path to free "replay_map" when ocfs2_truncate_log_init() fails. And fix the second problem by calling ocfs2_free_replay_slots(osb) in the error handling path "out_dismount". In addition, since ocfs2_free_replay_slots() is static, it is necessary to remove its static attribute and declare it in header file.
--- fs/ocfs2/journal.c | 2 +- fs/ocfs2/journal.h | 1 + fs/ocfs2/super.c | 5 ++++- 3 files changed, 6 insertions(+), 2 deletions(-)
fs/ocfs2/journal.c +1 -1
@@ -157,7 +157,7 @@ static void ocfs2_queue_replay_slots(struct ocfs2_super *osb, replay_map->rm_state =REPLAY_DONE ; } -static void ocfs2_free_replay_slots (struct ocfs2_super *osb) +void ocfs2_free_replay_slots (struct ocfs2_super *osb) {struct ocfs2_replay_map *replay_map = osb->replay_map;
fs/ocfs2/journal.h +1 -0
@@ -150,6 +150,7 @@ int ocfs2_recovery_init(struct ocfs2_super *osb);void ocfs2_recovery_exit (struct ocfs2_super *osb);int ocfs2_compute_replay_slots (struct ocfs2_super *osb); +void ocfs2_free_replay_slots (struct ocfs2_super *osb);/* * Journal Control: * Initialize, Load, Shutdown, Wipe a journal.
fs/ocfs2/super.c +4 -1
@@ -1160,6 +1160,7 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent) out_dismount:atomic_set (&osb->vol_state,VOLUME_DISABLED );wake_up (&osb->osb_mount_event); +ocfs2_free_replay_slots (osb);ocfs2_dismount_volume (sb,1 ); goto out;
@@ -1825,12 +1826,14 @@ static int ocfs2_mount_volume(struct super_block *sb) status =ocfs2_truncate_log_init (osb);if (status <0 ) {mlog_errno (status); - goto out_system_inodes; + goto out_check_volume; }ocfs2_super_unlock (osb,1 );return 0 ; +out_check_volume: +ocfs2_free_replay_slots (osb); out_system_inodes:if (osb->local_alloc_state ==OCFS2_LA_ENABLED )ocfs2_shutdown_local_alloc (osb);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 11/93 NFSD: Fix sparse warning
In reply to Greg Kroah-HartmanFrom: Chuck Lever <[email protected]>
[ Upstream commit c2f1c4bd20621175c581f298b4943df0cffbd841 ]
/home/cel/src/linux/linux/fs/nfsd/nfs4proc.c:1539:24: warning: incorrect type in assignment (different base types)/home/cel/src/linux/linux/fs/nfsd/nfs4proc.c:1539:24: expected restricted __be32 [usertype] status/home/cel/src/linux/linux/fs/nfsd/nfs4proc.c:1539:24: got int
Stable-dep-of: 79a1d88a36f7 ("NFSD: pass range end to vfs_fsync_range() instead of count")
--- fs/nfsd/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfsd/nfs4proc.c +1 -1
@@ -1513,7 +1513,7 @@ static ssize_t _nfsd_copy_file_range(struct nfsd4_copy *copy)u64 bytes_total = copy->cp_count;u64 src_pos = copy->cp_src_pos;u64 dst_pos = copy->cp_dst_pos; -__be32 status; +int status;/* See RFC 7862 p.67: */ if (bytes_total ==0 )
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 12/93 NFSD: pass range end to vfs_fsync_range() instead of count
In reply to Greg Kroah-HartmanFrom: Brian Foster <[email protected]>
[ Upstream commit 79a1d88a36f77374c77fd41a4386d8c2736b8704 ]
_nfsd_copy_file_range() calls vfs_fsync_range() with an offset and count (bytes written), but the former wants the start and end bytes of the range to sync. Fix it up.
--- fs/nfsd/nfs4proc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
fs/nfsd/nfs4proc.c +3 -2
@@ -1514,6 +1514,7 @@ static ssize_t _nfsd_copy_file_range(struct nfsd4_copy *copy)u64 src_pos = copy->cp_src_pos;u64 dst_pos = copy->cp_dst_pos;int status; +loff_t end;/* See RFC 7862 p.67: */ if (bytes_total ==0 )
@@ -1533,8 +1534,8 @@ static ssize_t _nfsd_copy_file_range(struct nfsd4_copy *copy)/* for a non-zero asynchronous copy do a commit of data */ if (!copy->cp_synchronous && copy->cp_res.wr_bytes_written >0 ) { since =READ_ONCE (dst->f_wb_err); - status =vfs_fsync_range (dst, copy->cp_dst_pos, - copy->cp_res.wr_bytes_written,0 ); + end = copy->cp_dst_pos + copy->cp_res.wr_bytes_written -1 ; + status =vfs_fsync_range (dst, copy->cp_dst_pos, end,0 );if (!status) status =filemap_check_wb_err (dst->f_mapping, since);if (!status)
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 13/93 RDMA/irdma: Do not request 2-level PBLEs for CQ alloc
In reply to Greg Kroah-HartmanFrom: Mustafa Ismail <[email protected]>
[ Upstream commit 8f7e2daa6336f9f4b6f8a4715a809674606df16b ]
When allocating PBLE's for a large CQ, it is possible that a 2-level PBLE is returned which would cause the CQ allocation to fail since 1-level is assumed and checked for. Fix this by requesting a level one PBLE only.
--- drivers/infiniband/hw/irdma/verbs.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-)
drivers/infiniband/hw/irdma/verbs.c +5 -10
@@ -2272,9 +2272,10 @@ static bool irdma_check_mr_contiguous(struct irdma_pble_alloc *palloc,* @rf: RDMA PCI function * @iwmr: mr pointer for this memory registration * @use_pbles: flag if to use pble's +* @lvl_1_only: request only level 1 pble if true */ static int irdma_setup_pbles (struct irdma_pci_f *rf,struct irdma_mr *iwmr, -bool use_pbles) +bool use_pbles,bool lvl_1_only) {struct irdma_pbl *iwpbl = &iwmr->iwpbl;struct irdma_pble_alloc *palloc = &iwpbl->pble_alloc;
@@ -2285,7 +2286,7 @@ static int irdma_setup_pbles(struct irdma_pci_f *rf, struct irdma_mr *iwmr,if (use_pbles) { status =irdma_get_pble (rf->pble_rsrc, palloc, iwmr->page_cnt, - false); + lvl_1_only);if (status)return -ENOMEM ;
@@ -2328,16 +2329,10 @@ static int irdma_handle_q_mem(struct irdma_device *iwdev,bool ret = true; pg_size = iwmr->page_size; - err =irdma_setup_pbles (iwdev->rf, iwmr, use_pbles); + err =irdma_setup_pbles (iwdev->rf, iwmr, use_pbles, true);if (err)return err; -if (use_pbles && palloc->level !=PBLE_LEVEL_1 ) { -irdma_free_pble (iwdev->rf->pble_rsrc, palloc); - iwpbl->pbl_allocated = false; -return -ENOMEM ; - } -if (use_pbles) arr = palloc->level1.addr;
@@ -2808,7 +2803,7 @@ static struct ib_mr *irdma_reg_user_mr(struct ib_pd *pd, u64 start, u64 len,case IRDMA_MEMREG_TYPE_MEM : use_pbles = (iwmr->page_cnt !=1 ); - err =irdma_setup_pbles (iwdev->rf, iwmr, use_pbles); + err =irdma_setup_pbles (iwdev->rf, iwmr, use_pbles, false);if (err) goto error;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 14/93 platform/x86: int3472: Split into 2 drivers
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
[ Upstream commit a2f9fbc247eea0ad1b0b59bc29bec144c5ead03c ]
The intel_skl_int3472.ko module contains 2 separate drivers, the int3472_discrete platform driver and the int3472_tps68470 I2C-driver.
These 2 drivers contain very little shared code, only skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are shared.
Split the module into 2 drivers, linking the little shared code directly into both.
This will allow us to add soft-module dependencies for the tps68470 clk, gpio and regulator drivers to the new intel_skl_int3472_tps68470.ko to help with probe ordering issues without causing these modules to get loaded on boards which only use the int3472_discrete platform driver.
While at it also rename the .c and .h files to remove the cumbersome intel_skl_int3472_ prefix.
Stable-dep-of: cf5ac2d45f6e ("platform/x86: int3472/discrete: Ensure the clk/power enable pins are in output mode")
---
drivers/platform/x86/intel/int3472/Makefile | 9 +-
...lk_and_regulator.c => clk_and_regulator.c} | 2 +-
drivers/platform/x86/intel/int3472/common.c | 54 +++++++++
.../{intel_skl_int3472_common.h => common.h} | 3 -
...ntel_skl_int3472_discrete.c => discrete.c} | 28 ++++-
.../intel/int3472/intel_skl_int3472_common.c | 106 ------------------
...ntel_skl_int3472_tps68470.c => tps68470.c} | 23 +++-
7 files changed, 105 insertions(+), 120 deletions(-)
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_clk_and_regulator.c => clk_and_regulator.c} (99%)
create mode 100644 drivers/platform/x86/intel/int3472/common.c
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_common.h => common.h} (94%)
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_discrete.c => discrete.c} (93%)
delete mode 100644 drivers/platform/x86/intel/int3472/intel_skl_int3472_common.c
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_tps68470.c => tps68470.c} (85%)drivers/platform/x86/intel/int3472/Makefile +4 -5
@@ -1,5 +1,4 @@ -obj-$(CONFIG_INTEL_SKL_INT3472) += intel_skl_int3472.o -intel_skl_int3472-y := intel_skl_int3472_common.o \ - intel_skl_int3472_discrete.o \ - intel_skl_int3472_tps68470.o \ - intel_skl_int3472_clk_and_regulator.o +obj-$(CONFIG_INTEL_SKL_INT3472) += intel_skl_int3472_discrete.o \ + intel_skl_int3472_tps68470.o +intel_skl_int3472_discrete-y := discrete.o clk_and_regulator.o common.o +intel_skl_int3472_tps68470-y := tps68470.o common.o
drivers/platform/x86/intel/int3472/clk_and_regulator.c renamed from drivers/platform/x86/intel/int3472/intel_skl_int3472_clk_and_regulator.c +1 -1
@@ -9,7 +9,7 @@#include <linux/regulator/driver.h> #include <linux/slab.h> -#include "intel_skl_int3472_common.h" +#include "common.h" /* * The regulators have to have .ops to be valid, but the only ops we actually
drivers/platform/x86/intel/int3472/common.c new file +54 -0
54 lines not on this page · raw message
drivers/platform/x86/intel/int3472/common.h renamed from drivers/platform/x86/intel/int3472/intel_skl_int3472_common.h +0 -3
@@ -105,9 +105,6 @@ struct int3472_discrete_device {struct gpiod_lookup_table gpios; }; -int skl_int3472_discrete_probe (struct platform_device *pdev); -int skl_int3472_discrete_remove (struct platform_device *pdev); -int skl_int3472_tps68470_probe (struct i2c_client *client);union acpi_object *skl_int3472_get_acpi_buffer (struct acpi_device *adev,char *id);int skl_int3472_fill_cldb (struct acpi_device *adev,struct int3472_cldb *cldb);
drivers/platform/x86/intel/int3472/discrete.c renamed from drivers/platform/x86/intel/int3472/intel_skl_int3472_discrete.c +25 -3
@@ -14,7 +14,7 @@#include <linux/platform_device.h> #include <linux/uuid.h> -#include "intel_skl_int3472_common.h" +#include "common.h" /* * 79234640-9e10-4fea-a5c1-b5aa8b19756f
@@ -332,7 +332,9 @@ static int skl_int3472_parse_crs(struct int3472_discrete_device *int3472)return 0 ; } -int skl_int3472_discrete_probe (struct platform_device *pdev) +static int skl_int3472_discrete_remove (struct platform_device *pdev); + +static int skl_int3472_discrete_probe (struct platform_device *pdev) {struct acpi_device *adev =ACPI_COMPANION (&pdev->dev);struct int3472_discrete_device *int3472;
@@ -395,7 +397,7 @@ int skl_int3472_discrete_probe(struct platform_device *pdev)return ret; } -int skl_int3472_discrete_remove (struct platform_device *pdev) +static int skl_int3472_discrete_remove (struct platform_device *pdev) {struct int3472_discrete_device *int3472 =platform_get_drvdata (pdev);
@@ -411,3 +413,23 @@ int skl_int3472_discrete_remove(struct platform_device *pdev)return 0 ; } + +static const struct acpi_device_id int3472_device_id[] = { + {"INT3472" ,0 }, + { } +}; +MODULE_DEVICE_TABLE (acpi, int3472_device_id); + +static struct platform_driver int3472_discrete = { + .driver = { + .name ="int3472-discrete" , + .acpi_match_table = int3472_device_id, + }, + .probe = skl_int3472_discrete_probe, + .remove = skl_int3472_discrete_remove, +}; +module_platform_driver (int3472_discrete); + +MODULE_DESCRIPTION ("Intel SkyLake INT3472 ACPI Discrete Device Driver" ); +MODULE_AUTHOR ("Daniel Scally <[email protected]>" ); +MODULE_LICENSE ("GPL v2" );
drivers/platform/x86/intel/int3472/intel_skl_int3472_common.c deleted +0 -106
106 lines not on this page · raw message
drivers/platform/x86/intel/int3472/tps68470.c renamed from drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c +21 -2
@@ -7,7 +7,7 @@#include <linux/platform_device.h> #include <linux/regmap.h> -#include "intel_skl_int3472_common.h" +#include "common.h" #define DESIGNED_FOR_CHROMEOS 1#define DESIGNED_FOR_WINDOWS 2
@@ -95,7 +95,7 @@ static int skl_int3472_tps68470_calc_type(struct acpi_device *adev)return DESIGNED_FOR_WINDOWS ; } -int skl_int3472_tps68470_probe (struct i2c_client *client) +static int skl_int3472_tps68470_probe (struct i2c_client *client) {struct acpi_device *adev =ACPI_COMPANION (&client->dev);struct regmap *regmap;
@@ -135,3 +135,22 @@ int skl_int3472_tps68470_probe(struct i2c_client *client)return ret; } + +static const struct acpi_device_id int3472_device_id[] = { + {"INT3472" ,0 }, + { } +}; +MODULE_DEVICE_TABLE (acpi, int3472_device_id); + +static struct i2c_driver int3472_tps68470 = { + .driver = { + .name ="int3472-tps68470" , + .acpi_match_table = int3472_device_id, + }, + .probe_new = skl_int3472_tps68470_probe, +}; +module_i2c_driver (int3472_tps68470); + +MODULE_DESCRIPTION ("Intel SkyLake INT3472 ACPI TPS68470 Device Driver" ); +MODULE_AUTHOR ("Daniel Scally <[email protected]>" ); +MODULE_LICENSE ("GPL v2" );
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 15/93 platform/x86: int3472/discrete: Ensure the clk/power enable pins are in output mode
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
[ Upstream commit cf5ac2d45f6e4d11ad78e7b10ae9a4121ba5e995 ]
acpi_get_and_request_gpiod() does not take a gpio_lookup_flags argument specifying that the pins direction should be initialized to a specific value.
This means that in some cases the pins might be left in input mode, causing the gpiod_set() calls made to enable the clk / regulator to not work.
One example of this problem is the clk-enable GPIO for the ov01a1s sensor on a Dell Latitude 9420 being left in input mode causing the clk to never get enabled.
Explicitly set the direction of the pins to output to fix this.
--- drivers/platform/x86/intel/int3472/clk_and_regulator.c | 3 +++ drivers/platform/x86/intel/int3472/discrete.c | 4 ++++ 2 files changed, 7 insertions(+)
drivers/platform/x86/intel/int3472/clk_and_regulator.c +3 -0
@@ -181,6 +181,9 @@ int skl_int3472_register_regulator(struct int3472_discrete_device *int3472,return PTR_ERR (int3472->regulator.gpio); } +/* Ensure the pin is in output mode and non-active state */ +gpiod_direction_output (int3472->regulator.gpio,0 ); + cfg.dev = &int3472->adev->dev; cfg.init_data = &init_data; cfg.ena_gpiod = int3472->regulator.gpio;
drivers/platform/x86/intel/int3472/discrete.c +4 -0
@@ -169,6 +169,8 @@ static int skl_int3472_map_gpio_to_clk(struct int3472_discrete_device *int3472,return (PTR_ERR (gpio)); int3472->clock.ena_gpio = gpio; +/* Ensure the pin is in output mode and non-active state */ +gpiod_direction_output (int3472->clock.ena_gpio,0 );break ;case INT3472_GPIO_TYPE_PRIVACY_LED : gpio =acpi_get_and_request_gpiod (path, pin,"int3472,privacy-led" );
@@ -176,6 +178,8 @@ static int skl_int3472_map_gpio_to_clk(struct int3472_discrete_device *int3472,return (PTR_ERR (gpio)); int3472->clock.led_gpio = gpio; +/* Ensure the pin is in output mode and non-active state */ +gpiod_direction_output (int3472->clock.led_gpio,0 );break ;default :dev_err (int3472->dev,"Invalid GPIO type 0x%02x for clock\n" , type);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 16/93 iavf: return errno code instead of status code
In reply to Greg Kroah-HartmanFrom: Jacob Keller <[email protected]>
[ Upstream commit 9f4651ea3e07339b460d403ff01b7cc2178fef7b ]
The iavf_parse_cls_flower function returns an integer error code, and not an iavf_status enumeration.
Fix the function to use the standard errno value EINVAL as its return instead of using IAVF_ERR_CONFIG.
Stable-dep-of: 6650c8e906ce ("iavf/iavf_main: actually log ->src mask when talking about it")
--- drivers/net/ethernet/intel/iavf/iavf_main.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
drivers/net/ethernet/intel/iavf/iavf_main.c +10 -10
@@ -3103,7 +3103,7 @@ static int iavf_parse_cls_flower(struct iavf_adapter *adapter, }else {dev_err (&adapter->pdev->dev,"Bad ether dest mask %pM\n" , match.mask->dst); -return IAVF_ERR_CONFIG ; +return -EINVAL ; } }
@@ -3113,7 +3113,7 @@ static int iavf_parse_cls_flower(struct iavf_adapter *adapter, }else {dev_err (&adapter->pdev->dev,"Bad ether src mask %pM\n" , match.mask->src); -return IAVF_ERR_CONFIG ; +return -EINVAL ; } }
@@ -3148,7 +3148,7 @@ static int iavf_parse_cls_flower(struct iavf_adapter *adapter, }else {dev_err (&adapter->pdev->dev,"Bad vlan mask %u\n" , match.mask->vlan_id); -return IAVF_ERR_CONFIG ; +return -EINVAL ; } } vf->mask.tcp_spec.vlan_id |=cpu_to_be16 (0xffff );
@@ -3172,7 +3172,7 @@ static int iavf_parse_cls_flower(struct iavf_adapter *adapter, }else {dev_err (&adapter->pdev->dev,"Bad ip dst mask 0x%08x\n" ,be32_to_cpu (match.mask->dst)); -return IAVF_ERR_CONFIG ; +return -EINVAL ; } }
@@ -3182,13 +3182,13 @@ static int iavf_parse_cls_flower(struct iavf_adapter *adapter, }else {dev_err (&adapter->pdev->dev,"Bad ip src mask 0x%08x\n" ,be32_to_cpu (match.mask->dst)); -return IAVF_ERR_CONFIG ; +return -EINVAL ; } }if (field_flags &IAVF_CLOUD_FIELD_TEN_ID ) {dev_info (&adapter->pdev->dev,"Tenant id not allowed for ip filter\n" ); -return IAVF_ERR_CONFIG ; +return -EINVAL ; }if (match.key->dst) { vf->mask.tcp_spec.dst_ip[0 ] |=cpu_to_be32 (0xffffffff );
@@ -3209,7 +3209,7 @@ static int iavf_parse_cls_flower(struct iavf_adapter *adapter,if (ipv6_addr_any (&match.mask->dst)) {dev_err (&adapter->pdev->dev,"Bad ipv6 dst mask 0x%02x\n" ,IPV6_ADDR_ANY ); -return IAVF_ERR_CONFIG ; +return -EINVAL ; }/* src and dest IPv6 address should not be LOOPBACK
@@ -3219,7 +3219,7 @@ static int iavf_parse_cls_flower(struct iavf_adapter *adapter, ipv6_addr_loopback(&match.key->src)) {dev_err (&adapter->pdev->dev,"ipv6 addr should not be loopback\n" ); -return IAVF_ERR_CONFIG ; +return -EINVAL ; }if (!ipv6_addr_any (&match.mask->dst) || !ipv6_addr_any (&match.mask->src))
@@ -3244,7 +3244,7 @@ static int iavf_parse_cls_flower(struct iavf_adapter *adapter, }else {dev_err (&adapter->pdev->dev,"Bad src port mask %u\n" ,be16_to_cpu (match.mask->src)); -return IAVF_ERR_CONFIG ; +return -EINVAL ; } }
@@ -3254,7 +3254,7 @@ static int iavf_parse_cls_flower(struct iavf_adapter *adapter, }else {dev_err (&adapter->pdev->dev,"Bad dst port mask %u\n" ,be16_to_cpu (match.mask->dst)); -return IAVF_ERR_CONFIG ; +return -EINVAL ; } }if (match.key->dst) {
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 17/93 iavf/iavf_main: actually log ->src mask when talking about it
In reply to Greg Kroah-HartmanFrom: Daniil Tatianin <[email protected]>
[ Upstream commit 6650c8e906ce58404bfdfceceeba7bd10d397d40 ]
This fixes a copy-paste issue where dev_err would log the dst mask even though it is clearly talking about src.
Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
--- drivers/net/ethernet/intel/iavf/iavf_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/iavf/iavf_main.c +1 -1
@@ -3181,7 +3181,7 @@ static int iavf_parse_cls_flower(struct iavf_adapter *adapter, field_flags |=IAVF_CLOUD_FIELD_IIP ; }else {dev_err (&adapter->pdev->dev,"Bad ip src mask 0x%08x\n" , -be32_to_cpu (match.mask->dst)); +be32_to_cpu (match.mask->src));return -EINVAL ; } }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 18/93 serial: 8250_exar: derive nr_ports from PCI ID for Acces I/O cards
In reply to Greg Kroah-HartmanFrom: Andy Shevchenko <[email protected]>
[ Upstream commit 8e4413aaf6a2e3a46e99a0718ca54c0cf8609cb2 ]
In the similar way how it's done in 8250_pericom, derive the number of the UART ports from PCI ID for Acces I/O cards.
Stable-dep-of: 14ee78d5932a ("serial: exar: Add support for Sealevel 7xxxC serial cards")
--- drivers/tty/serial/8250/8250_exar.c | 37 ++++++++++------------------- 1 file changed, 13 insertions(+), 24 deletions(-)
drivers/tty/serial/8250/8250_exar.c +13 -24
@@ -623,7 +623,12 @@ exar_pci_probe(struct pci_dev *pcidev, const struct pci_device_id *ent) maxnr =pci_resource_len (pcidev, bar) >> (board->reg_shift +3 ); - nr_ports = board->num_ports ? board->num_ports : pcidev->device &0x0f ; +if (pcidev->vendor ==PCI_VENDOR_ID_ACCESSIO ) + nr_ports =BIT (((pcidev->device &0x38 ) >>3 ) -1 ); +else if (board->num_ports) + nr_ports = board->num_ports; +else + nr_ports = pcidev->device &0x0f ; priv =devm_kzalloc (&pcidev->dev,struct_size (priv, line, nr_ports),GFP_KERNEL );if (!priv)
@@ -722,22 +727,6 @@ static int __maybe_unused exar_resume(struct device *dev) static SIMPLE_DEV_PM_OPS(exar_pci_pm, exar_suspend, exar_resume); -static const struct exar8250_board acces_com_2x = { - .num_ports =2 , - .setup = pci_xr17c154_setup, -}; - -static const struct exar8250_board acces_com_4x = { - .num_ports =4 , - .setup = pci_xr17c154_setup, -}; - -static const struct exar8250_board acces_com_8x = { - .num_ports =8 , - .setup = pci_xr17c154_setup, -}; - -static const struct exar8250_board pbn_fastcom335_2 = { .num_ports =2 , .setup = pci_fastcom335_setup,
@@ -822,13 +811,13 @@ static const struct exar8250_board pbn_exar_XR17V8358 = { }static const struct pci_device_id exar_pci_tbl[] = { -EXAR_DEVICE (ACCESSIO ,COM_2S , acces_com_2x), -EXAR_DEVICE (ACCESSIO ,COM_4S , acces_com_4x), -EXAR_DEVICE (ACCESSIO ,COM_8S , acces_com_8x), -EXAR_DEVICE (ACCESSIO ,COM232_8 , acces_com_8x), -EXAR_DEVICE (ACCESSIO ,COM_2SM , acces_com_2x), -EXAR_DEVICE (ACCESSIO ,COM_4SM , acces_com_4x), -EXAR_DEVICE (ACCESSIO ,COM_8SM , acces_com_8x), +EXAR_DEVICE (ACCESSIO ,COM_2S , pbn_exar_XR17C15x), +EXAR_DEVICE (ACCESSIO ,COM_4S , pbn_exar_XR17C15x), +EXAR_DEVICE (ACCESSIO ,COM_8S , pbn_exar_XR17C15x), +EXAR_DEVICE (ACCESSIO ,COM232_8 , pbn_exar_XR17C15x), +EXAR_DEVICE (ACCESSIO ,COM_2SM , pbn_exar_XR17C15x), +EXAR_DEVICE (ACCESSIO ,COM_4SM , pbn_exar_XR17C15x), +EXAR_DEVICE (ACCESSIO ,COM_8SM , pbn_exar_XR17C15x),CONNECT_DEVICE (XR17C152 ,UART_2_232 , pbn_connect),CONNECT_DEVICE (XR17C154 ,UART_4_232 , pbn_connect),
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 19/93 serial: exar: Add support for Sealevel 7xxxC serial cards
In reply to Greg Kroah-HartmanFrom: Matthew Howell <[email protected]>
[ Upstream commit 14ee78d5932afeb710c8305196a676a715bfdea8 ]
Add support for Sealevel 7xxxC serial cards.
This patch:
* Adds IDs to recognize 7xxxC cards from Sealevel Systems.
* Updates exar_pci_probe() to set nr_ports to last two bytes of primary dev ID for these cards.
--- drivers/tty/serial/8250/8250_exar.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/tty/serial/8250/8250_exar.c +14 -0
@@ -43,6 +43,12 @@#define PCI_DEVICE_ID_EXAR_XR17V4358 0x4358#define PCI_DEVICE_ID_EXAR_XR17V8358 0x8358 +#define PCI_DEVICE_ID_SEALEVEL_710xC 0x1001 +#define PCI_DEVICE_ID_SEALEVEL_720xC 0x1002 +#define PCI_DEVICE_ID_SEALEVEL_740xC 0x1004 +#define PCI_DEVICE_ID_SEALEVEL_780xC 0x1008 +#define PCI_DEVICE_ID_SEALEVEL_716xC 0x1010 +#define UART_EXAR_INT0 0x80#define UART_EXAR_8XMODE 0x88/* 8X sampling rate select */ #define UART_EXAR_SLEEP 0x8b/* Sleep mode */
@@ -627,6 +633,8 @@ exar_pci_probe(struct pci_dev *pcidev, const struct pci_device_id *ent) nr_ports =BIT (((pcidev->device &0x38 ) >>3 ) -1 ); else if (board->num_ports) nr_ports = board->num_ports; + else if (pcidev->vendor == PCI_VENDOR_ID_SEALEVEL) + nr_ports = pcidev->device &0xff ; else nr_ports = pcidev->device &0x0f ;
@@ -853,6 +861,12 @@ static const struct pci_device_id exar_pci_tbl[] = { EXAR_DEVICE(COMMTECH, 4224PCI335, pbn_fastcom335_4), EXAR_DEVICE(COMMTECH, 2324PCI335, pbn_fastcom335_4), EXAR_DEVICE(COMMTECH, 2328PCI335, pbn_fastcom335_8), + + EXAR_DEVICE(SEALEVEL, 710xC, pbn_exar_XR17V35x), + EXAR_DEVICE(SEALEVEL, 720xC, pbn_exar_XR17V35x), + EXAR_DEVICE(SEALEVEL, 740xC, pbn_exar_XR17V35x), + EXAR_DEVICE(SEALEVEL, 780xC, pbn_exar_XR17V35x), + EXAR_DEVICE(SEALEVEL, 716xC, pbn_exar_XR17V35x), { 0, } };MODULE_DEVICE_TABLE (pci, exar_pci_tbl);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 20/93 drm/amdgpu: Prevent race between late signaled fences and GPU reset.
In reply to Greg Kroah-HartmanFrom: Andrey Grodzovsky <[email protected]>
[ Upstream commit 9e225fb9e636b31b97e9d35324c2f9e43ee0aab4 ]
Problem:
After we start handling timed out jobs we assume there fences won't be signaled but we cannot be sure and sometimes they fire late. We need to prevent concurrent accesses to fence array from amdgpu_fence_driver_clear_job_fences during GPU reset and amdgpu_fence_process from a late EOP interrupt.
Fix:
Before accessing fence array in GPU disable EOP interrupt and flush all pending interrupt handlers for amdgpu device's interrupt line.
v2: Switch from irq_get/put to full enable/disable_irq for amdgpu
Stable-dep-of: 1427a7202739 ("drm/amdgpu: fix amdgpu_job_free_resources v2")
--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++++ drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 18 ++++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 + 3 files changed, 23 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +4 -0
@@ -4609,6 +4609,8 @@ int amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,amdgpu_virt_fini_data_exchange (adev); } +amdgpu_fence_driver_isr_toggle (adev, true); +/* block all schedulers and reset given job's ring */ for (i =0 ; i <AMDGPU_MAX_RINGS ; ++i) {struct amdgpu_ring *ring = adev->rings[i];
@@ -4631,6 +4633,8 @@ int amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,amdgpu_fence_driver_force_completion (ring); } +amdgpu_fence_driver_isr_toggle (adev, false); +if (job && job->vm)drm_sched_increase_karma (&job->base);
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +18 -0
@@ -569,6 +569,24 @@ void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev) } } +/* Will either stop and flush handlers for amdgpu interrupt or reanble it */ +void amdgpu_fence_driver_isr_toggle (struct amdgpu_device *adev,bool stop) +{ +int i; + +for (i =0 ; i <AMDGPU_MAX_RINGS ; i++) { +struct amdgpu_ring *ring = adev->rings[i]; + +if (!ring || !ring->fence_drv.initialized || !ring->fence_drv.irq_src) +continue ; + +if (stop) +disable_irq (adev->irq.irq); +else +enable_irq (adev->irq.irq); + } +} +void amdgpu_fence_driver_sw_fini (struct amdgpu_device *adev) {unsigned int i, j;
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h +1 -0
@@ -131,6 +131,7 @@ signed long amdgpu_fence_wait_polling(struct amdgpu_ring *ring,uint32_t wait_seq, signed long timeout);unsigned amdgpu_fence_count_emitted (struct amdgpu_ring *ring); +void amdgpu_fence_driver_isr_toggle (struct amdgpu_device *adev,bool stop);/* * Rings.
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 21/93 drm/amdgpu: fix amdgpu_job_free_resources v2
In reply to Greg Kroah-HartmanFrom: Christian König <[email protected]>
[ Upstream commit 1427a720273976a81d13d9d9fa60d53ce881cbd7 ]
It can be that neither fence were initialized when we run out of UVD streams for example.
v2: fix typo breaking compile
--- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c +8 -2
@@ -135,8 +135,14 @@ void amdgpu_job_free_resources(struct amdgpu_job *job)else hw_fence = &job->hw_fence; -/* use sched fence if available */ - f = job->base.s_fence ? &job->base.s_fence->finished : hw_fence; +/* Check if any fences where initialized */ +if (job->base.s_fence && job->base.s_fence->finished.ops) + f = &job->base.s_fence->finished; +else if (job->hw_fence.ops) + f = &job->hw_fence; +else + f =NULL ; +for (i =0 ; i < job->num_ibs; ++i)amdgpu_ib_free (ring->adev, &job->ibs[i], f); }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 22/93 bpf: hash map, avoid deadlock with suitable hash mask
In reply to Greg Kroah-HartmanFrom: Tonghao Zhang <[email protected]>
[ Upstream commit 9f907439dc80e4a2fcfb949927b36c036468dbb3 ]
The deadlock still may occur while accessed in NMI and non-NMI context. Because in NMI, we still may access the same bucket but with different map_locked index.
For example, on the same CPU, .max_entries = 2, we update the hash map, with key = 4, while running bpf prog in NMI nmi_handle(), to update hash map with key = 20, so it will have the same bucket index but have different map_locked index.
To fix this issue, using min mask to hash again.
--- kernel/bpf/hashtab.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/bpf/hashtab.c +2 -2
@@ -163,7 +163,7 @@ static inline int htab_lock_bucket(const struct bpf_htab *htab,unsigned long flags;bool use_raw_lock; - hash = hash &HASHTAB_MAP_LOCK_MASK ; + hash = hash &min_t (u32,HASHTAB_MAP_LOCK_MASK , htab->n_buckets -1 ); use_raw_lock =htab_use_raw_lock (htab);if (use_raw_lock)
@@ -194,7 +194,7 @@ static inline void htab_unlock_bucket(const struct bpf_htab *htab, {bool use_raw_lock =htab_use_raw_lock (htab); - hash = hash &HASHTAB_MAP_LOCK_MASK ; + hash = hash &min_t (u32,HASHTAB_MAP_LOCK_MASK , htab->n_buckets -1 );if (use_raw_lock)raw_spin_unlock_irqrestore (&b->raw_lock, flags);else
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 23/93 gpio: GPIO_REGMAP: select REGMAP instead of depending on it
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit d49765b5f4320a402fbc4ed5edfd73d87640f27c ]
REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it.
Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues.
Therefore, change the use of "depends on REGMAP" to "select REGMAP".
--- drivers/gpio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/Kconfig +1 -1
@@ -100,7 +100,7 @@ config GPIO_GENERIC tristate config GPIO_REGMAP - depends on REGMAP + select REGMAP tristate # put drivers in the right section, in alphabetical order
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 24/93 Drivers: vmbus: Check for channel allocation before looking up relids
In reply to Greg Kroah-HartmanFrom: Mohammed Gamal <[email protected]>
[ Upstream commit 1eb65c8687316c65140b48fad27133d583178e15 ]
relid2channel() assumes vmbus channel array to be allocated when called. However, in cases such as kdump/kexec, not all relids will be reset by the host. When the second kernel boots and if the guest receives a vmbus interrupt during vmbus driver initialization before vmbus_connect() is called, before it finishes, or if it fails, the vmbus interrupt service routine is called which in turn calls relid2channel() and can cause a null pointer dereference.
Print a warning and error out in relid2channel() for a channel id that's invalid in the second kernel.
--- drivers/hv/connection.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/hv/connection.c +4 -0
@@ -315,6 +315,10 @@ void vmbus_disconnect(void)*/ struct vmbus_channel *relid2channel (u32 relid) { +if (vmbus_connection.channels ==NULL ) { +pr_warn_once ("relid2channel: relid=%d: No channels mapped!\n" , relid); +return NULL ; + }if (WARN_ON (relid >=MAX_CHANNEL_RELIDS ))return NULL ;return READ_ONCE (vmbus_connection.channels[relid]);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 25/93 pwm: cros-ec: Explicitly set .polarity in .get_state()
In reply to Greg Kroah-HartmanFrom: Uwe Kleine-König <[email protected]>
[ Upstream commit 30006b77c7e130e01d1ab2148cc8abf73dfcc4bf ]
The driver only supports normal polarity. Complete the implementation of .get_state() by setting .polarity accordingly.
--- drivers/pwm/pwm-cros-ec.c | 1 + 1 file changed, 1 insertion(+)
drivers/pwm/pwm-cros-ec.c +1 -0
@@ -157,6 +157,7 @@ static void cros_ec_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, state->enabled = (ret >0 ); state->period =EC_PWM_MAX_DUTY ; + state->polarity =PWM_POLARITY_NORMAL ;/* * Note that "disabled" and "duty cycle == 0" are treated the same. If
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 26/93 pwm: sprd: Explicitly set .polarity in .get_state()
In reply to Greg Kroah-HartmanFrom: Uwe Kleine-König <[email protected]>
[ Upstream commit 2be4dcf6627e1bcbbef8e6ba1811f5127d39202c ]
The driver only supports normal polarity. Complete the implementation of .get_state() by setting .polarity accordingly.
--- drivers/pwm/pwm-sprd.c | 1 + 1 file changed, 1 insertion(+)
drivers/pwm/pwm-sprd.c +1 -0
@@ -109,6 +109,7 @@ static void sprd_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, duty = val &SPRD_PWM_DUTY_MSK ; tmp = (prescale +1 ) *NSEC_PER_SEC * duty; state->duty_cycle =DIV_ROUND_CLOSEST_ULL (tmp, chn->clk_rate); + state->polarity =PWM_POLARITY_NORMAL ;/* Disable PWM clocks if the PWM channel is not in enable state. */ if (!state->enabled)
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 27/93 KVM: s390: pv: fix external interruption loop not always detected
In reply to Greg Kroah-HartmanFrom: Nico Boehr <[email protected]>
[ Upstream commit 21f27df854008b86349a203bf97fef79bb11f53e ]
To determine whether the guest has caused an external interruption loop upon code 20 (external interrupt) intercepts, the ext_new_psw needs to be inspected to see whether external interrupts are enabled.
Under non-PV, ext_new_psw can simply be taken from guest lowcore. Under PV, KVM can only access the encrypted guest lowcore and hence the ext_new_psw must not be taken from guest lowcore.
handle_external_interrupt() incorrectly did that and hence was not able to reliably tell whether an external interruption loop is happening or not. False negatives cause spurious failures of my kvm-unit-test for extint loops[1] under PV.
Since code 20 is only caused under PV if and only if the guest's ext_new_psw is enabled for external interrupts, false positive detection of a external interruption loop can not happen.
Fix this issue by instead looking at the guest PSW in the state description. Since the PSW swap for external interrupt is done by the ultravisor before the intercept is caused, this reliably tells whether the guest is enabled for external interrupts in the ext_new_psw.
Also update the comments to explain better what is happening.
[1] https://lore.kernel.org/kvm/[email protected]/
Message-Id: <[email protected]>
--- arch/s390/kvm/intercept.c | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-)
arch/s390/kvm/intercept.c +24 -8
@@ -271,10 +271,18 @@ static int handle_prog(struct kvm_vcpu *vcpu)* handle_external_interrupt - used for external interruption interceptions * @vcpu: virtual cpu * -* This interception only occurs if the CPUSTAT_EXT_INT bit was set, or if -* the new PSW does not have external interrupts disabled. In the first case, -* we've got to deliver the interrupt manually, and in the second case, we -* drop to userspace to handle the situation there. +* This interception occurs if: +* - the CPUSTAT_EXT_INT bit was already set when the external interrupt +* occurred. In this case, the interrupt needs to be injected manually to +* preserve interrupt priority. +* - the external new PSW has external interrupts enabled, which will cause an +* interruption loop. We drop to userspace in this case. +* +* The latter case can be detected by inspecting the external mask bit in the +* external new psw. +* +* Under PV, only the latter case can occur, since interrupt priorities are +* handled in the ultravisor. */ static int handle_external_interrupt (struct kvm_vcpu *vcpu) {
@@ -285,10 +293,18 @@ static int handle_external_interrupt(struct kvm_vcpu *vcpu) vcpu->stat.exit_external_interrupt++; - rc =read_guest_lc (vcpu, __LC_EXT_NEW_PSW, &newpsw,sizeof (psw_t)); -if (rc) -return rc; -/* We can not handle clock comparator or timer interrupt with bad PSW */ +if (kvm_s390_pv_cpu_is_protected (vcpu)) { + newpsw = vcpu->arch.sie_block->gpsw; + }else { + rc =read_guest_lc (vcpu, __LC_EXT_NEW_PSW, &newpsw,sizeof (psw_t)); +if (rc) +return rc; + } + +/* +* Clock comparator or timer interrupt with external interrupt enabled +* will cause interrupt loop. Drop to userspace. +*/ if ((eic ==EXT_IRQ_CLK_COMP || eic ==EXT_IRQ_CPU_TIMER ) && (newpsw.mask &PSW_MASK_EXT ))return -EOPNOTSUPP ;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 28/93 wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta
In reply to Greg Kroah-HartmanFrom: Felix Fietkau <[email protected]>
[ Upstream commit 12b220a6171faf10638ab683a975cadcf1a352d6 ]
Avoid potential data corruption issues caused by uninitialized driver private data structures.
--- net/mac80211/sta_info.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/mac80211/sta_info.c +2 -1
@@ -1036,7 +1036,8 @@ static int __must_check __sta_info_destroy_part1(struct sta_info *sta)list_del_rcu (&sta->list); sta->removed = true; -drv_sta_pre_rcu_remove (local, sta->sdata, sta); +if (sta->uploaded) +drv_sta_pre_rcu_remove (local, sta->sdata, sta);if (sdata->vif.type ==NL80211_IFTYPE_AP_VLAN &&rcu_access_pointer (sdata->u.vlan.sta) == sta)
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 29/93 net: qrtr: combine nameservice into main module
In reply to Greg Kroah-HartmanFrom: Luca Weiss <[email protected]>
[ Upstream commit a365023a76f231cc2fc6e33797e66f3bcaa9f9a9 ]
Previously with CONFIG_QRTR=m a separate ns.ko would be built which wasn't done on purpose and should be included in qrtr.ko.
Rename qrtr.c to af_qrtr.c so we can build a qrtr.ko with both af_qrtr.c and ns.c.
Stable-dep-of: 44d807320000 ("net: qrtr: Fix a refcount bug in qrtr_recvmsg()")
---
net/qrtr/Makefile | 3 ++-
net/qrtr/{qrtr.c => af_qrtr.c} | 0
2 files changed, 2 insertions(+), 1 deletion(-)
rename net/qrtr/{qrtr.c => af_qrtr.c} (100%)net/qrtr/Makefile +2 -1
@@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only -obj-$(CONFIG_QRTR) := qrtr.o ns.o +obj-$(CONFIG_QRTR) += qrtr.o +qrtr-y := af_qrtr.o ns.o obj-$(CONFIG_QRTR_SMD) += qrtr-smd.o qrtr-smd-y := smd.o
net/qrtr/af_qrtr.c renamed from net/qrtr/qrtr.c +0 -0
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 30/93 net: qrtr: Fix a refcount bug in qrtr_recvmsg()
In reply to Greg Kroah-HartmanFrom: Ziyang Xuan <[email protected]>
[ Upstream commit 44d807320000db0d0013372ad39b53e12d52f758 ]
Syzbot reported a bug as following:
refcount_t: addition on 0; use-after-free.
...
RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25 ... Call Trace: <TASK> __refcount_add include/linux/refcount.h:199 [inline] __refcount_inc include/linux/refcount.h:250 [inline] refcount_inc include/linux/refcount.h:267 [inline] kref_get include/linux/kref.h:45 [inline] qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline] qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline] qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline] qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070 sock_recvmsg_nosec net/socket.c:1017 [inline] sock_recvmsg+0xe2/0x160 net/socket.c:1038 qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688 process_one_work+0x991/0x15c0 kernel/workqueue.c:2390 worker_thread+0x669/0x1090 kernel/workqueue.c:2537
It occurs in the concurrent scenario of qrtr_recvmsg() and qrtr_endpoint_unregister() as following:
cpu0 cpu1
qrtr_recvmsg qrtr_endpoint_unregisterqrtr_send_resume_tx qrtr_node_releaseqrtr_node_lookup mutex_lock(&qrtr_node_lock)spin_lock_irqsave(&qrtr_nodes_lock, ) refcount_dec_and_test(&node->ref) [node->ref == 0]radix_tree_lookup [node != NULL] __qrtr_node_releaseqrtr_node_acquire spin_lock_irqsave(&qrtr_nodes_lock, )kref_get(&node->ref) [WARNING] ...
mutex_unlock(&qrtr_node_lock)
Use qrtr_node_lock to protect qrtr_node_lookup() implementation, this is actually improving the protection of node reference.
--- net/qrtr/af_qrtr.c | 2 ++ 1 file changed, 2 insertions(+)
net/qrtr/af_qrtr.c +2 -0
@@ -393,10 +393,12 @@ static struct qrtr_node *qrtr_node_lookup(unsigned int nid)struct qrtr_node *node;unsigned long flags; +mutex_lock (&qrtr_node_lock);spin_lock_irqsave (&qrtr_nodes_lock, flags); node =radix_tree_lookup (&qrtr_nodes, nid); node =qrtr_node_acquire (node);spin_unlock_irqrestore (&qrtr_nodes_lock, flags); +mutex_unlock (&qrtr_node_lock);return node; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 31/93 NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL
In reply to Greg Kroah-HartmanFrom: Chuck Lever <[email protected]>
[ Upstream commit 804d8e0a6e54427268790472781e03bc243f4ee3 ]
OPDESC() simply indexes into nfsd4_ops[] by the op's operation number, without range checking that value. It assumes callers are careful to avoid calling it with an out-of-bounds opnum value.
nfsd4_decode_compound() is not so careful, and can invoke OPDESC() with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end of nfsd4_ops[].
--- fs/nfsd/nfs4xdr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/nfsd/nfs4xdr.c +3 -1
@@ -2370,10 +2370,12 @@ nfsd4_decode_compound(struct nfsd4_compoundargs *argp)for (i =0 ; i < argp->opcnt; i++) { op = &argp->ops[i]; op->replay =NULL ; + op->opdesc =NULL ;if (xdr_stream_decode_u32 (argp->xdr, &op->opnum) <0 )return 0 ;if (nfsd4_opnum_in_range (argp, op)) { + op->opdesc =OPDESC (op); op->status = nfsd4_dec_ops[op->opnum](argp, &op->u);if (op->status != nfs_ok) trace_nfsd_compound_decode_err(argp->rqstp,
@@ -2384,7 +2386,7 @@ nfsd4_decode_compound(struct nfsd4_compoundargs *argp) op->opnum =OP_ILLEGAL ; op->status = nfserr_op_illegal; } - op->opdesc =OPDESC (op); +/* * We'll try to cache the result in the DRC if any one * op in the compound wants to be cached:
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 32/93 icmp: guard against too small mtu
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 7d63b67125382ff0ffdfca434acbc94a38bd092b ]
syzbot was able to trigger a panic [1] in icmp_glue_bits(), or more exactly in skb_copy_and_csum_bits()
There is no repro yet, but I think the issue is that syzbot manages to lower device mtu to a small value, fooling __icmp_send()
__icmp_send() must make sure there is enough room for the packet to include at least the headers.
We might in the future refactor skb_copy_and_csum_bits() and its callers to no longer crash when something bad happens.
[1]
kernel BUG at net/core/skbuff.c:3343 !
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 15766 Comm: syz-executor.0 Not tainted 6.3.0-rc4-syzkaller-00039-gffe78bbd5121 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 RIP: 0010:skb_copy_and_csum_bits+0x798/0x860 net/core/skbuff.c:3343 Code: f0 c1 c8 08 41 89 c6 e9 73 ff ff ff e8 61 48 d4 f9 e9 41 fd ff ff 48 8b 7c 24 48 e8 52 48 d4 f9 e9 c3 fc ff ff e8 c8 27 84 f9 <0f> 0b 48 89 44 24 28 e8 3c 48 d4 f9 48 8b 44 24 28 e9 9d fb ff ff RSP: 0018:ffffc90000007620 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000001e8 RCX: 0000000000000100 RDX: ffff8880276f6280 RSI: ffffffff87fdd138 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000000001e8 R11: 0000000000000001 R12: 000000000000003c R13: 0000000000000000 R14: ffff888028244868 R15: 0000000000000b0e FS: 00007fbc81f1c700(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2df43000 CR3: 00000000744db000 CR4: 0000000000150ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> icmp_glue_bits+0x7b/0x210 net/ipv4/icmp.c:353 __ip_append_data+0x1d1b/0x39f0 net/ipv4/ip_output.c:1161 ip_append_data net/ipv4/ip_output.c:1343 [inline] ip_append_data+0x115/0x1a0 net/ipv4/ip_output.c:1322 icmp_push_reply+0xa8/0x440 net/ipv4/icmp.c:370 __icmp_send+0xb80/0x1430 net/ipv4/icmp.c:765 ipv4_send_dest_unreach net/ipv4/route.c:1239 [inline] ipv4_link_failure+0x5a9/0x9e0 net/ipv4/route.c:1246 dst_link_failure include/net/dst.h:423 [inline] arp_error_report+0xcb/0x1c0 net/ipv4/arp.c:296 neigh_invalidate+0x20d/0x560 net/core/neighbour.c:1079 neigh_timer_handler+0xc77/0xff0 net/core/neighbour.c:1166 call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700 expire_timers+0x29b/0x4b0 kernel/time/timer.c:1751 __run_timers kernel/time/timer.c:2022 [inline]
--- net/ipv4/icmp.c | 5 +++++ 1 file changed, 5 insertions(+)
net/ipv4/icmp.c +5 -0
@@ -755,6 +755,11 @@ void __icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info, room =576 ; room -=sizeof (struct iphdr ) + icmp_param.replyopts.opt.opt.optlen; room -=sizeof (struct icmphdr ); +/* Guard against tiny mtu. We need to include at least one +* IP network header for this message to make any sense. +*/ +if (room <= (int )sizeof (struct iphdr )) + goto ende; icmp_param.data_len = skb_in->len - icmp_param.offset;if (icmp_param.data_len > room)
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 33/93 net: dont let netpoll invoke NAPI if in xmit context
In reply to Greg Kroah-HartmanFrom: Jakub Kicinski <[email protected]>
[ Upstream commit 275b471e3d2daf1472ae8fa70dc1b50c9e0b9e75 ]
Commit 0db3dc73f7a3 ("[NETPOLL]: tx lock deadlock fix") narrowed down the region under netif_tx_trylock() inside netpoll_send_skb(). (At that point in time netif_tx_trylock() would lock all queues of the device.) Taking the tx lock was problematic because driver's cleanup method may take the same lock. So the change made us hold the xmit lock only around xmit, and expected the driver to take care of locking within ->ndo_poll_controller().
Unfortunately this only works if netpoll isn't itself called with the xmit lock already held. Netpoll code is careful and uses trylock(). The drivers, however, may be using plain lock(). Printing while holding the xmit lock is going to result in rare deadlocks.
Luckily we record the xmit lock owners, so we can scan all the queues, the same way we scan NAPI owners. If any of the xmit locks is held by the local CPU we better not attempt any polling.
It would be nice if we could narrow down the check to only the NAPIs and the queue we're trying to use. I don't see a way to do that now.
--- net/core/netpoll.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
net/core/netpoll.c +18 -1
@@ -137,6 +137,20 @@ static void queue_process(struct work_struct *work) } } +static int netif_local_xmit_active (struct net_device *dev) +{ +int i; + +for (i =0 ; i < dev->num_tx_queues; i++) { +struct netdev_queue *txq =netdev_get_tx_queue (dev, i); + +if (READ_ONCE (txq->xmit_lock_owner) ==smp_processor_id ()) +return 1 ; + } + +return 0 ; +} +static void poll_one_napi (struct napi_struct *napi) {int work;
@@ -183,7 +197,10 @@ void netpoll_poll_dev(struct net_device *dev)if (!ni ||down_trylock (&ni->dev_lock))return ; -if (!netif_running (dev)) { +/* Some drivers will take the same locks in poll and xmit, +* we can't poll if local CPU is already in xmit. +*/ +if (!netif_running (dev) ||netif_local_xmit_active (dev)) {up (&ni->dev_lock);return ; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 34/93 net: dsa: mv88e6xxx: Reset mv88e6393x force WD event bit
In reply to Greg Kroah-HartmanFrom: Gustav Ekelund <[email protected]>
[ Upstream commit 089b91a0155c4de1209a07ff2a7dd299ff3ece47 ]
The force watchdog event bit is not cleared during SW reset in the mv88e6393x switch. This is a different behavior compared to mv886390 which clears the force WD event bit as advertised. This causes a force WD event to be handled over and over again as the SW reset following the event never clears the force WD event bit.
Explicitly clear the watchdog event register to 0 in irq_action when handling an event to prevent the switch from sending continuous interrupts. Marvell aren't aware of any other stuck bits apart from the force WD bit.
--- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- drivers/net/dsa/mv88e6xxx/global2.c | 20 ++++++++++++++++++++ drivers/net/dsa/mv88e6xxx/global2.h | 1 + 3 files changed, 22 insertions(+), 1 deletion(-)
drivers/net/dsa/mv88e6xxx/chip.c +1 -1
@@ -4967,7 +4967,7 @@ static const struct mv88e6xxx_ops mv88e6393x_ops = {* .port_set_upstream_port method. */ .set_egress_port = mv88e6393x_set_egress_port, - .watchdog_ops = &mv88e6390_watchdog_ops, + .watchdog_ops = &mv88e6393x_watchdog_ops, .mgmt_rsvd2cpu = mv88e6393x_port_mgmt_rsvd2cpu, .pot_clear = mv88e6xxx_g2_pot_clear, .reset = mv88e6352_g1_reset,
drivers/net/dsa/mv88e6xxx/global2.c +20 -0
@@ -931,6 +931,26 @@ const struct mv88e6xxx_irq_ops mv88e6390_watchdog_ops = { .irq_free = mv88e6390_watchdog_free, }; +static int mv88e6393x_watchdog_action (struct mv88e6xxx_chip *chip,int irq) +{ +mv88e6390_watchdog_action (chip, irq); + +/* Fix for clearing the force WD event bit. +* Unreleased erratum on mv88e6393x. +*/ +mv88e6xxx_g2_write (chip,MV88E6390_G2_WDOG_CTL , +MV88E6390_G2_WDOG_CTL_UPDATE | +MV88E6390_G2_WDOG_CTL_PTR_EVENT ); + +return IRQ_HANDLED ; +} + +const struct mv88e6xxx_irq_ops mv88e6393x_watchdog_ops = { + .irq_action = mv88e6393x_watchdog_action, + .irq_setup = mv88e6390_watchdog_setup, + .irq_free = mv88e6390_watchdog_free, +}; +static irqreturn_t mv88e6xxx_g2_watchdog_thread_fn (int irq,void *dev_id) {struct mv88e6xxx_chip *chip = dev_id;
drivers/net/dsa/mv88e6xxx/global2.h +1 -0
@@ -361,6 +361,7 @@ int mv88e6xxx_g2_device_mapping_write(struct mv88e6xxx_chip *chip, int target,extern const struct mv88e6xxx_irq_ops mv88e6097_watchdog_ops;extern const struct mv88e6xxx_irq_ops mv88e6250_watchdog_ops;extern const struct mv88e6xxx_irq_ops mv88e6390_watchdog_ops; +extern const struct mv88e6xxx_irq_ops mv88e6393x_watchdog_ops;extern const struct mv88e6xxx_avb_ops mv88e6165_avb_ops;extern const struct mv88e6xxx_avb_ops mv88e6352_avb_ops;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 35/93 sctp: check send stream number after wait_for_sndbuf
In reply to Greg Kroah-HartmanFrom: Xin Long <[email protected]>
[ Upstream commit 2584024b23552c00d95b50255e47bd18d306d31a ]
This patch fixes a corner case where the asoc out stream count may change after wait_for_sndbuf.
When the main thread in the client starts a connection, if its out stream count is set to N while the in stream count in the server is set to N - 2, another thread in the client keeps sending the msgs with stream number N - 1, and waits for sndbuf before processing INIT_ACK.
However, after processing INIT_ACK, the out stream count in the client is shrunk to N - 2, the same to the in stream count in the server. The crash occurs when the thread waiting for sndbuf is awake and sends the msg in a non-existing stream(N - 1), the call trace is as below:
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] Call Trace: <TASK> sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline] sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170 sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163 sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868 sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825 sock_sendmsg_nosec net/socket.c:722 [inline] sock_sendmsg+0xde/0x190 net/socket.c:745
The fix is to add an unlikely check for the send stream number after the thread wakes up from the wait_for_sndbuf.
--- net/sctp/socket.c | 4 ++++ 1 file changed, 4 insertions(+)
net/sctp/socket.c +4 -0
@@ -1831,6 +1831,10 @@ static int sctp_sendmsg_to_asoc(struct sctp_association *asoc, err =sctp_wait_for_sndbuf (asoc, &timeo, msg_len);if (err) goto err; +if (unlikely (sinfo->sinfo_stream >= asoc->stream.outcnt)) { + err = -EINVAL ; + goto err; + } }if (sctp_state (asoc,CLOSED )) {
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 36/93 net: qrtr: Do not do DEL_SERVER broadcast after DEL_CLIENT
In reply to Greg Kroah-HartmanFrom: Sricharan Ramabadhran <[email protected]>
[ Upstream commit 839349d13905927d8a567ca4d21d88c82028e31d ]
On the remote side, when QRTR socket is removed, af_qrtr will call qrtr_port_remove() which broadcasts the DEL_CLIENT packet to all neighbours including local NS. NS upon receiving the DEL_CLIENT packet, will remove the lookups associated with the node:port and broadcasts the DEL_SERVER packet.
But on the host side, due to the arrival of the DEL_CLIENT packet, the NS would've already deleted the server belonging to that port. So when the remote's NS again broadcasts the DEL_SERVER for that port, it throws below error message on the host:
"failed while handling packet from 2:-2"
So fix this error by not broadcasting the DEL_SERVER packet when the DEL_CLIENT packet gets processed."
--- net/qrtr/ns.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
net/qrtr/ns.c +9 -6
@@ -273,7 +273,7 @@ static struct qrtr_server *server_add(unsigned int service,return NULL ; } -static int server_del (struct qrtr_node *node,unsigned int port) +static int server_del (struct qrtr_node *node,unsigned int port,bool bcast) {struct qrtr_lookup *lookup;struct qrtr_server *srv;
@@ -286,7 +286,7 @@ static int server_del(struct qrtr_node *node, unsigned int port)radix_tree_delete (&node->servers, port);/* Broadcast the removal of local servers */ -if (srv->node == qrtr_ns.local_node) +if (srv->node == qrtr_ns.local_node && bcast)service_announce_del (&qrtr_ns.bcast_sq, srv);/* Announce the service's disappearance to observers */
@@ -372,7 +372,7 @@ static int ctrl_cmd_bye(struct sockaddr_qrtr *from) } slot =radix_tree_iter_resume (slot, &iter);rcu_read_unlock (); -server_del (node, srv->port); +server_del (node, srv->port, true);rcu_read_lock (); }rcu_read_unlock ();
@@ -458,10 +458,13 @@ static int ctrl_cmd_del_client(struct sockaddr_qrtr *from,kfree (lookup); } -/* Remove the server belonging to this port */ +/* Remove the server belonging to this port but don't broadcast +* DEL_SERVER. Neighbours would've already removed the server belonging +* to this port due to the DEL_CLIENT broadcast from qrtr_port_remove(). +*/ node =node_get (node_id);if (node) -server_del (node, port); +server_del (node, port, false);/* Advertise the removal of this client to all local servers */ local_node =node_get (qrtr_ns.local_node);
@@ -566,7 +569,7 @@ static int ctrl_cmd_del_server(struct sockaddr_qrtr *from,if (!node)return -ENOENT ; -return server_del (node, port); +return server_del (node, port, true); } static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from,
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 37/93 ipv6: Fix an uninit variable access bug in __ip6_make_skb()
In reply to Greg Kroah-HartmanFrom: Ziyang Xuan <[email protected]>
[ Upstream commit ea30388baebcce37fd594d425a65037ca35e59e8 ]
Syzbot reported a bug as following:
=====================================================
BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 ip6_finish_skb include/net/ipv6.h:1122 [inline] ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987 rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579 rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Uninit was created at:
slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 alloc_skb include/linux/skbuff.h:1270 [inline] __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684 ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854 rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
It is because icmp6hdr does not in skb linear region under the scenario of SOCK_RAW socket. Access icmp6_hdr(skb)->icmp6_type directly will trigger the uninit variable access bug.
Use a local variable icmp6_type to carry the correct value in different scenarios.
--- net/ipv6/ip6_output.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
net/ipv6/ip6_output.c +6 -1
@@ -1913,8 +1913,13 @@ struct sk_buff *__ip6_make_skb(struct sock *sk,IP6_UPD_PO_STATS (net, rt->rt6i_idev,IPSTATS_MIB_OUT , skb->len);if (proto ==IPPROTO_ICMPV6 ) {struct inet6_dev *idev =ip6_dst_idev (skb_dst (skb)); +u8 icmp6_type; -ICMP6MSGOUT_INC_STATS (net, idev,icmp6_hdr (skb)->icmp6_type); +if (sk->sk_socket->type ==SOCK_RAW && !inet_sk (sk)->hdrincl) + icmp6_type = fl6->fl6_icmp_type; +else + icmp6_type =icmp6_hdr (skb)->icmp6_type; +ICMP6MSGOUT_INC_STATS (net, idev, icmp6_type);ICMP6_INC_STATS (net, idev,ICMP6_MIB_OUTMSGS ); }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 38/93 platform/x86: think-lmi: Fix memory leak when showing current settings
In reply to Greg Kroah-HartmanFrom: Armin Wolf <[email protected]>
[ Upstream commit a3c4c053014585dcf20f4df954791b74d8a8afcd ]
When retriving a item string with tlmi_setting(), the result has to be freed using kfree(). In current_value_show() however, malformed item strings are not freed, causing a memory leak.
Fix this by eliminating the early return responsible for this.
--- drivers/platform/x86/think-lmi.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/platform/x86/think-lmi.c +4 -2
@@ -514,10 +514,12 @@ static ssize_t current_value_show(struct kobject *kobj, struct kobj_attribute *a/* validate and split from `item,value` -> `value` */ value =strpbrk (item,"," );if (!value || value == item || !strlen (value +1 )) -return -EINVAL ; + ret = -EINVAL ; +else + ret =sysfs_emit (buf,"%s\n" , value +1 ); - ret =sysfs_emit (buf,"%s\n" , value +1 );kfree (item); +return ret; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 39/93 platform/x86: think-lmi: Fix memory leaks when parsing ThinkStation WMI strings
In reply to Greg Kroah-HartmanFrom: Mark Pearson <[email protected]>
[ Upstream commit e7d796fccdc8d17c2d21817ebe4c7bf5bbfe5433 ]
My previous commit introduced a memory leak where the item allocated from tlmi_setting was not freed.
This commit also renames it to avoid confusion with the similarly name variable in the same function.
--- drivers/platform/x86/think-lmi.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/platform/x86/think-lmi.c +4 -3
@@ -952,10 +952,10 @@ static int tlmi_analyze(void)* name string. * Try and pull that out if it's available. */ -char *item, *optstart, *optend; +char *optitem, *optstart, *optend; -if (!tlmi_setting (setting->index, &item,LENOVO_BIOS_SETTING_GUID )) { - optstart =strstr (item,"[Optional:" ); +if (!tlmi_setting (setting->index, &optitem,LENOVO_BIOS_SETTING_GUID )) { + optstart =strstr (optitem,"[Optional:" );if (optstart) { optstart +=strlen ("[Optional:" ); optend =strstr (optstart,"]" );
@@ -964,6 +964,7 @@ static int tlmi_analyze(void)kstrndup (optstart, optend - optstart,GFP_KERNEL ); } +kfree (optitem); } }/*
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 40/93 platform/x86: think-lmi: Clean up display of current_value on Thinkstation
In reply to Greg Kroah-HartmanFrom: Mark Pearson <[email protected]>
[ Upstream commit 7065655216d4d034d71164641f3bec0b189ad6fa ]
On ThinkStations on retrieving the attribute value the BIOS appends the possible values to the string.
Clean up the display in the current_value_show function so the options part is not displayed.
Reported by Mario Limoncello <[email protected]>
--- drivers/platform/x86/think-lmi.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/platform/x86/think-lmi.c +6 -3
@@ -504,7 +504,7 @@ static ssize_t display_name_show(struct kobject *kobj, struct kobj_attribute *atstatic ssize_t current_value_show (struct kobject *kobj,struct kobj_attribute *attr,char *buf) {struct tlmi_attr_setting *setting =to_tlmi_attr_setting (kobj); -char *item, *value; +char *item, *value, *p;int ret; ret =tlmi_setting (setting->index, &item,LENOVO_BIOS_SETTING_GUID );
@@ -515,9 +515,12 @@ static ssize_t current_value_show(struct kobject *kobj, struct kobj_attribute *a value =strpbrk (item,"," );if (!value || value == item || !strlen (value +1 )) ret = -EINVAL ; -else +else { +/* On Workstations remove the Options part after the value */ + p =strchrnul (value,';' ); + *p ='\0' ; ret =sysfs_emit (buf,"%s\n" , value +1 ); - + }kfree (item);return ret;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 41/93 gpio: davinci: Add irq chip flag to skip set wake
In reply to Greg Kroah-HartmanFrom: Dhruva Gole <[email protected]>
[ Upstream commit 7b75c4703609a3ebaf67271813521bc0281e1ec1 ]
Add the IRQCHIP_SKIP_SET_WAKE flag since there are no special IRQ Wake bits that can be set to enable wakeup IRQ.
--- drivers/gpio/gpio-davinci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpio-davinci.c +1 -1
@@ -326,7 +326,7 @@ static struct irq_chip gpio_irqchip = { .irq_enable = gpio_irq_enable, .irq_disable = gpio_irq_disable, .irq_set_type = gpio_irq_type, - .flags = IRQCHIP_SET_TYPE_MASKED, + .flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_SKIP_SET_WAKE, };static void gpio_irq_handler (struct irq_desc *desc)
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 42/93 net: ethernet: ti: am65-cpsw: Fix mdio cleanup in probe
In reply to Greg Kroah-HartmanFrom: Siddharth Vadapalli <[email protected]>
[ Upstream commit c6b486fb33680ad5a3a6390ce693c835caaae3f7 ]
In the am65_cpsw_nuss_probe() function's cleanup path, the call to of_platform_device_destroy() for the common->mdio_dev device is invoked unconditionally. It is possible that either the MDIO node is not present in the device-tree, or the MDIO node is disabled in the device-tree. In both these cases, the MDIO device is not created, resulting in a NULL pointer dereference when the of_platform_device_destroy() function is invoked on the common->mdio_dev device on the cleanup path.
Fix this by ensuring that the common->mdio_dev device exists, before attempting to invoke of_platform_device_destroy().
--- drivers/net/ethernet/ti/am65-cpsw-nuss.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/ethernet/ti/am65-cpsw-nuss.c +4 -2
@@ -2784,7 +2784,8 @@ static int am65_cpsw_nuss_probe(struct platform_device *pdev)return 0 ; err_of_clear: -of_platform_device_destroy (common->mdio_dev,NULL ); +if (common->mdio_dev) +of_platform_device_destroy (common->mdio_dev,NULL ); err_pm_clear:pm_runtime_put_sync (dev);pm_runtime_disable (dev);
@@ -2813,7 +2814,8 @@ static int am65_cpsw_nuss_remove(struct platform_device *pdev)*/ am65_cpsw_nuss_cleanup_ndev (common); -of_platform_device_destroy (common->mdio_dev,NULL ); +if (common->mdio_dev) +of_platform_device_destroy (common->mdio_dev,NULL );pm_runtime_put_sync (&pdev->dev);pm_runtime_disable (&pdev->dev);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 43/93 net: stmmac: fix up RX flow hash indirection table when setting channels
In reply to Greg Kroah-HartmanFrom: Corinna Vinschen <[email protected]>
[ Upstream commit 218c597325f4faf7b7a6049233a30d7842b5b2dc ]
stmmac_reinit_queues() fails to fix up the RX hash. Even if the number of channels gets restricted, the output of `ethtool -x' indicates that all RX queues are used:
$ ethtool -l enp0s29f2
Channel parameters for enp0s29f2:
Pre-set maximums:
RX: 8
TX: 8
Other: n/a
Combined: n/a
Current hardware settings:
RX: 8
TX: 8
Other: n/a
Combined: n/a
$ ethtool -x enp0s29f2
RX flow hash indirection table for enp0s29f2 with 8 RX ring(s):
0: 0 1 2 3 4 5 6 7
8: 0 1 2 3 4 5 6 7
[...]
$ ethtool -L enp0s29f2 rx 3
$ ethtool -x enp0s29f2
RX flow hash indirection table for enp0s29f2 with 3 RX ring(s):
0: 0 1 2 3 4 5 6 7
8: 0 1 2 3 4 5 6 7
[...]Fix this by setting the indirection table according to the number of specified queues. The result is now as expected:
$ ethtool -L enp0s29f2 rx 3
$ ethtool -x enp0s29f2
RX flow hash indirection table for enp0s29f2 with 3 RX ring(s):
0: 0 1 2 0 1 2 0 1
8: 2 0 1 2 0 1 2 0
[...]Tested on Intel Elkhart Lake.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +5 -1
@@ -6893,7 +6893,7 @@ static void stmmac_napi_del(struct net_device *dev)int stmmac_reinit_queues (struct net_device *dev,u32 rx_cnt,u32 tx_cnt) {struct stmmac_priv *priv =netdev_priv (dev); -int ret =0 ; +int ret =0 , i;if (netif_running (dev))stmmac_release (dev);
@@ -6902,6 +6902,10 @@ int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt) priv->plat->rx_queues_to_use = rx_cnt; priv->plat->tx_queues_to_use = tx_cnt; +if (!netif_is_rxfh_configured (dev)) +for (i =0 ; i <ARRAY_SIZE (priv->rss.table); i++) + priv->rss.table[i] =ethtool_rxfh_indir_default (i, + rx_cnt);stmmac_napi_add (dev);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 44/93 sunrpc: only free unix grouplist after RCU settles
In reply to Greg Kroah-HartmanFrom: Jeff Layton <[email protected]>
[ Upstream commit 5085e41f9e83a1bec51da1f20b54f2ec3a13a3fe ]
While the unix_gid object is rcu-freed, the group_info list that it contains is not. Ensure that we only put the group list reference once we are really freeing the unix_gid object.
--- net/sunrpc/svcauth_unix.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
net/sunrpc/svcauth_unix.c +13 -4
@@ -415,14 +415,23 @@ static int unix_gid_hash(kuid_t uid)return hash_long (from_kuid (&init_user_ns, uid),GID_HASHBITS ); } -static void unix_gid_put (struct kref *kref) +static void unix_gid_free (struct rcu_head *rcu) { - struct cache_head *item = container_of(kref, struct cache_head, ref); - struct unix_gid *ug = container_of(item, struct unix_gid, h); + struct unix_gid *ug = container_of(rcu, struct unix_gid, rcu); +struct cache_head *item = &ug->h; +if (test_bit (CACHE_VALID , &item->flags) && !test_bit (CACHE_NEGATIVE , &item->flags))put_group_info (ug->gi); -kfree_rcu (ug, rcu); +kfree (ug); +} + +static void unix_gid_put (struct kref *kref) +{ + struct cache_head *item = container_of(kref, struct cache_head, ref); + struct unix_gid *ug = container_of(item, struct unix_gid, h); + +call_rcu (&ug->rcu, unix_gid_free); }static int unix_gid_match (struct cache_head *corig,struct cache_head *cnew)
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 45/93 NFSD: callback request does not use correct credential for AUTH_SYS
In reply to Greg Kroah-HartmanFrom: Dai Ngo <[email protected]>
[ Upstream commit 7de82c2f36fb26aa78440bbf0efcf360b691d98b ]
Currently callback request does not use the credential specified in CREATE_SESSION if the security flavor for the back channel is AUTH_SYS.
Problem was discovered by pynfs 4.1 DELEG5 and DELEG7 test with error:
DELEG5 st_delegation.testCBSecParms : FAILURE
expected callback with uid, gid == 17, 19, got 0, 0
--- fs/nfsd/nfs4callback.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfsd/nfs4callback.c +2 -2
@@ -875,8 +875,8 @@ static const struct cred *get_backchannel_cred(struct nfs4_client *clp, struct rif (!kcred)return NULL ; - kcred->uid = ses->se_cb_sec.uid; - kcred->gid = ses->se_cb_sec.gid; + kcred->fsuid = ses->se_cb_sec.uid; + kcred->fsgid = ses->se_cb_sec.gid;return kcred; } }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 46/93 ice: fix wrong fallback logic for FDIR
In reply to Greg Kroah-HartmanFrom: Simei Su <[email protected]>
[ Upstream commit b4a01ace20f5c93c724abffc0a83ec84f514b98d ]
When adding a FDIR filter, if ice_vc_fdir_set_irq_ctx returns failure, the inserted fdir entry will not be removed and if ice_vc_fdir_write_fltr returns failure, the fdir context info for irq handler will not be cleared which may lead to inconsistent or memory leak issue. This patch refines failure cases to resolve this issue.
--- drivers/net/ethernet/intel/ice/ice_virtchnl_fdir.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/net/ethernet/intel/ice/ice_virtchnl_fdir.c +4 -3
@@ -2136,7 +2136,7 @@ int ice_vc_add_fdir_fltr(struct ice_vf *vf, u8 *msg) v_ret =VIRTCHNL_STATUS_SUCCESS ; stat->status =VIRTCHNL_FDIR_FAILURE_RULE_NORESOURCE ;dev_dbg (dev,"VF %d: set FDIR context failed\n" , vf->vf_id); - goto err_free_conf; + goto err_rem_entry; } ret =ice_vc_fdir_write_fltr (vf, conf, true, is_tun);
@@ -2145,15 +2145,16 @@ int ice_vc_add_fdir_fltr(struct ice_vf *vf, u8 *msg) stat->status =VIRTCHNL_FDIR_FAILURE_RULE_NORESOURCE ;dev_err (dev,"VF %d: writing FDIR rule failed, ret:%d\n" , vf->vf_id, ret); - goto err_rem_entry; + goto err_clr_irq; } exit:kfree (stat);return ret; -err_rem_entry: +err_clr_irq:ice_vc_fdir_clear_irq_ctx (vf); +err_rem_entry:ice_vc_fdir_remove_entry (vf, conf, conf->flow_id); err_free_conf:devm_kfree (dev, conf);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 47/93 ice: Reset FDIR counter in FDIR init stage
In reply to Greg Kroah-HartmanFrom: Lingyu Liu <[email protected]>
[ Upstream commit 83c911dc5e0e8e6eaa6431c06972a8f159bfe2fc ]
Reset the FDIR counters when FDIR inits. Without this patch, when VF initializes or resets, all the FDIR counters are not cleaned, which may cause unexpected behaviors for future FDIR rule create (e.g., rule conflict).
--- .../net/ethernet/intel/ice/ice_virtchnl_fdir.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
drivers/net/ethernet/intel/ice/ice_virtchnl_fdir.c +16 -0
@@ -731,6 +731,21 @@ static void ice_vc_fdir_rem_prof_all(struct ice_vf *vf) } } +/** +* ice_vc_fdir_reset_cnt_all - reset all FDIR counters for this VF FDIR +* @fdir: pointer to the VF FDIR structure +*/ +static void ice_vc_fdir_reset_cnt_all (struct ice_vf_fdir *fdir) +{ +enum ice_fltr_ptype flow; + +for (flow =ICE_FLTR_PTYPE_NONF_NONE ; + flow <ICE_FLTR_PTYPE_MAX ; flow++) { + fdir->fdir_fltr_cnt[flow][0 ] =0 ; + fdir->fdir_fltr_cnt[flow][1 ] =0 ; + } +} +/** * ice_vc_fdir_has_prof_conflict * @vf: pointer to the VF structure
@@ -2263,6 +2278,7 @@ void ice_vf_fdir_init(struct ice_vf *vf)spin_lock_init (&fdir->ctx_lock); fdir->ctx_irq.flags =0 ; fdir->ctx_done.flags =0 ; +ice_vc_fdir_reset_cnt_all (fdir); }/**
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 48/93 ethtool: reset #lanes when lanes is omitted
In reply to Greg Kroah-HartmanFrom: Andy Roulin <[email protected]>
[ Upstream commit e847c7675e19ef344913724dc68f83df31ad6a17 ]
If the number of lanes was forced and then subsequently the user omits this parameter, the ksettings->lanes is reset. The driver should then reset the number of lanes to the device's default for the specified speed.
However, although the ksettings->lanes is set to 0, the mod variable is not set to true to indicate the driver and userspace should be notified of the changes.
The consequence is that the same ethtool operation will produce different results based on the initial state.
If the initial state is:
$ ethtool swp1 | grep -A 3 'Speed: '
Speed: 500000Mb/s
Lanes: 2
Duplex: Full
Auto-negotiation: onthen executing 'ethtool -s swp1 speed 50000 autoneg off' will yield:
$ ethtool swp1 | grep -A 3 'Speed: '
Speed: 500000Mb/s
Lanes: 2
Duplex: Full
Auto-negotiation: offWhile if the initial state is:
$ ethtool swp1 | grep -A 3 'Speed: '
Speed: 500000Mb/s
Lanes: 1
Duplex: Full
Auto-negotiation: offexecuting the same 'ethtool -s swp1 speed 50000 autoneg off' results in:
$ ethtool swp1 | grep -A 3 'Speed: '
Speed: 500000Mb/s
Lanes: 1
Duplex: Full
Auto-negotiation: offThis patch fixes this behavior. Omitting lanes will always results in the driver choosing the default lane width for the chosen speed. In this scenario, regardless of the initial state, the end state will be, e.g.,
$ ethtool swp1 | grep -A 3 'Speed: '
Speed: 500000Mb/s
Lanes: 2
Duplex: Full
Auto-negotiation: off--- net/ethtool/linkmodes.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
net/ethtool/linkmodes.c +4 -3
@@ -277,11 +277,12 @@ static int ethnl_update_linkmodes(struct genl_info *info, struct nlattr **tb, "lanes configuration not supported by device");return -EOPNOTSUPP ; } - }else if (!lsettings->autoneg) { -/* If autoneg is off and lanes parameter is not passed from user, -* set the lanes parameter to 0. + }else if (!lsettings->autoneg && ksettings->lanes) { +/* If autoneg is off and lanes parameter is not passed from user but +* it was defined previously then set the lanes parameter to 0. */ ksettings->lanes =0 ; + *mod = true; } ret = ethnl_update_bitset(ksettings->link_modes.advertising,
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 49/93 gve: Secure enough bytes in the first TX desc for all TCP pkts
In reply to Greg Kroah-HartmanFrom: Shailend Chand <[email protected]>
[ Upstream commit 3ce9345580974863c060fa32971537996a7b2d57 ]
Non-GSO TCP packets whose SKBs' linear portion did not include the entire TCP header were not populating the first Tx descriptor with as many bytes as the vNIC expected. This change ensures that all TCP packets populate the first descriptor with the correct number of bytes.
--- drivers/net/ethernet/google/gve/gve.h | 2 ++ drivers/net/ethernet/google/gve/gve_tx.c | 12 +++++------- 2 files changed, 7 insertions(+), 7 deletions(-)
drivers/net/ethernet/google/gve/gve.h +2 -0
@@ -47,6 +47,8 @@#define GVE_RX_BUFFER_SIZE_DQO 2048 +#define GVE_GQ_TX_MIN_PKT_DESC_BYTES 182 +/* Each slot in the desc ring has a 1:1 mapping to a slot in the data ring */ struct gve_rx_desc_queue {struct gve_rx_desc *desc_ring;/* the descriptor ring */
drivers/net/ethernet/google/gve/gve_tx.c +5 -7
@@ -283,8 +283,8 @@ static inline int gve_skb_fifo_bytes_required(struct gve_tx_ring *tx,int bytes;int hlen; - hlen =skb_is_gso (skb) ?skb_checksum_start_offset (skb) + -tcp_hdrlen (skb) :skb_headlen (skb); + hlen =skb_is_gso (skb) ?skb_checksum_start_offset (skb) +tcp_hdrlen (skb) : +min_t (int,GVE_GQ_TX_MIN_PKT_DESC_BYTES , skb->len); pad_bytes =gve_tx_fifo_pad_alloc_one_frag (&tx->tx_fifo, hlen);
@@ -431,13 +431,11 @@ static int gve_tx_add_skb_copy(struct gve_priv *priv, struct gve_tx_ring *tx, st pkt_desc = &tx->desc[idx]; l4_hdr_offset =skb_checksum_start_offset (skb); -/* If the skb is gso, then we want the tcp header in the first segment -* otherwise we want the linear portion of the skb (which will contain -* the checksum because skb->csum_start and skb->csum_offset are given -* relative to skb->head) in the first segment. +/* If the skb is gso, then we want the tcp header alone in the first segment +* otherwise we want the minimum required by the gVNIC spec. */ hlen = is_gso ? l4_hdr_offset +tcp_hdrlen (skb) : -skb_headlen (skb); +min_t (int,GVE_GQ_TX_MIN_PKT_DESC_BYTES , skb->len); info->skb = skb;/* We don't want to split the header, so if necessary, pad to the end
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 50/93 kbuild: refactor single builds of *.ko
In reply to Greg Kroah-HartmanFrom: Masahiro Yamada <[email protected]>
[ Upstream commit f110e5a250e3c5db417e094b3dd86f1c135291ca ]
Remove the potentially invalid modules.order instead of using the temporary file.
Also, KBUILD_MODULES is don't care for single builds. No need to cancel it.
Stable-dep-of: ed1f4ccfe947 ("clk: imx: imx8mp: add shared clk gate for usb suspend clk")
--- Makefile | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-)
Makefile +4 -12
@@ -1850,6 +1850,8 @@ modules modules_install: @echo >&2 '***' @exit 1 +KBUILD_MODULES := + endif # CONFIG_MODULES # Single targets
@@ -1875,18 +1877,12 @@ $(single-ko): single_modpost $(single-no-ko): descend @: -ifeq ($(KBUILD_EXTMOD),) -# For the single build of in-tree modules, use a temporary file to avoid -# the situation of modules_install installing an invalid modules.order. -MODORDER := .modules.tmp -endif - +# Remove MODORDER when done because it is not the real one. PHONY += single_modpost single_modpost: $(single-no-ko) modules_prepare $(Q){ $(foreach m, $(single-ko), echo $(extmod_prefix)$m;) } > $(MODORDER) $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost - -KBUILD_MODULES := 1 + $(Q)rm -f $(MODORDER) export KBUILD_SINGLE_TARGETS := $(addprefix $(extmod_prefix), $(single-no-ko))
@@ -1896,10 +1892,6 @@ build-dirs := $(foreach d, $(build-dirs), \ endif -ifndef CONFIG_MODULES -KBUILD_MODULES := -endif - # Handle descending into subdirectories listed in $(build-dirs) # Preset locale variables to speed up the build process. Limit locale # tweaks to this spot to avoid wrong language settings when running
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 51/93 usb: xhci: tegra: fix sleep in atomic call
In reply to Greg Kroah-HartmanFrom: Wayne Chang <[email protected]>
commit 4c7f9d2e413dc06a157c4e5dccde84aaf4655eb3 upstream.
When we set the dual-role port to Host mode, we observed the following splat:
[ 167.057718] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:229 [ 167.057872] Workqueue: events tegra_xusb_usb_phy_work [ 167.057954] Call trace: [ 167.057962] dump_backtrace+0x0/0x210 [ 167.057996] show_stack+0x30/0x50 [ 167.058020] dump_stack_lvl+0x64/0x84 [ 167.058065] dump_stack+0x14/0x34 [ 167.058100] __might_resched+0x144/0x180 [ 167.058140] __might_sleep+0x64/0xd0 [ 167.058171] slab_pre_alloc_hook.constprop.0+0xa8/0x110 [ 167.058202] __kmalloc_track_caller+0x74/0x2b0 [ 167.058233] kvasprintf+0xa4/0x190 [ 167.058261] kasprintf+0x58/0x90 [ 167.058285] tegra_xusb_find_port_node.isra.0+0x58/0xd0 [ 167.058334] tegra_xusb_find_port+0x38/0xa0 [ 167.058380] tegra_xusb_padctl_get_usb3_companion+0x38/0xd0 [ 167.058430] tegra_xhci_id_notify+0x8c/0x1e0 [ 167.058473] notifier_call_chain+0x88/0x100 [ 167.058506] atomic_notifier_call_chain+0x44/0x70 [ 167.058537] tegra_xusb_usb_phy_work+0x60/0xd0 [ 167.058581] process_one_work+0x1dc/0x4c0 [ 167.058618] worker_thread+0x54/0x410 [ 167.058650] kthread+0x188/0x1b0 [ 167.058672] ret_from_fork+0x10/0x20
The function tegra_xusb_padctl_get_usb3_companion eventually calls tegra_xusb_find_port and this in turn calls kasprintf which might sleep and so cannot be called from an atomic context.
Fix this by moving the call to tegra_xusb_padctl_get_usb3_companion to the tegra_xhci_id_work function where it is really needed.
--- drivers/usb/host/xhci-tegra.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/usb/host/xhci-tegra.c +3 -3
@@ -1225,6 +1225,9 @@ static void tegra_xhci_id_work(struct womutex_unlock (&tegra->lock); + tegra->otg_usb3_port =tegra_xusb_padctl_get_usb3_companion (tegra->padctl, + tegra->otg_usb2_port); +if (tegra->host_mode) {/* switch to host mode */ if (tegra->otg_usb3_port >=0 ) {
@@ -1339,9 +1342,6 @@ static int tegra_xhci_id_notify(struct n } tegra->otg_usb2_port =tegra_xusb_get_usb2_port (tegra, usbphy); - tegra->otg_usb3_port =tegra_xusb_padctl_get_usb3_companion ( - tegra->padctl, - tegra->otg_usb2_port); tegra->host_mode = (usbphy->last_event ==USB_EVENT_ID ) ? true : false;
Greg Kroah-Hartman
maintainerPATCH 52/93 xhci: also avoid the XHCI_ZERO_64B_REGS quirk with a passthrough iommu
In reply to Greg Kroah-HartmanFrom: D Scott Phillips <[email protected]>
commit ecaa4902439298f6b0e29f47424a86b310a9ff4f upstream.
Previously the quirk was skipped when no iommu was present. The same rationale for skipping the quirk also applies in the iommu.passthrough=1 case.
Skip applying the XHCI_ZERO_64B_REGS quirk if the device's iommu domain is passthrough.
--- drivers/usb/host/xhci.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/usb/host/xhci.c +5 -1
@@ -9,6 +9,7 @@*/ #include <linux/pci.h> +#include <linux/iommu.h> #include <linux/iopoll.h> #include <linux/irq.h> #include <linux/log2.h>
@@ -225,6 +226,7 @@ int xhci_reset(struct xhci_hcd *xhci, u6static void xhci_zero_64b_regs (struct xhci_hcd *xhci) {struct device *dev =xhci_to_hcd (xhci)->self.sysdev; +struct iommu_domain *domain;int err, i;u64 val;u32 intrs;
@@ -243,7 +245,9 @@ static void xhci_zero_64b_regs(struct xh* an iommu. Doing anything when there is no iommu is definitely * unsafe... */ -if (!(xhci->quirks &XHCI_ZERO_64B_REGS ) || !device_iommu_mapped (dev)) + domain =iommu_get_domain_for_dev (dev); +if (!(xhci->quirks &XHCI_ZERO_64B_REGS ) || !domain || + domain->type ==IOMMU_DOMAIN_IDENTITY )return ;xhci_info (xhci,"Zeroing 64bit base registers, expecting fault\n" );
Greg Kroah-Hartman
maintainerPATCH 53/93 usb: cdnsp: Fixes error: uninitialized symbol len
In reply to Greg Kroah-HartmanFrom: Pawel Laszczak <[email protected]>
commit 1edf48991a783d00a3a18dc0d27c88139e4030a2 upstream.
The patch 5bc38d33a5a1: "usb: cdnsp: Fixes issue with redundant Status Stage" leads to the following Smatch static checker warning:
drivers/usb/cdns3/cdnsp-ep0.c:470 cdnsp_setup_analyze()
error: uninitialized symbol 'len'.
--- drivers/usb/cdns3/cdnsp-ep0.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/usb/cdns3/cdnsp-ep0.c +1 -2
@@ -414,7 +414,7 @@ static int cdnsp_ep0_std_request(structvoid cdnsp_setup_analyze (struct cdnsp_device *pdev) {struct usb_ctrlrequest *ctrl = &pdev->setup; -int ret =0 ; +int ret = -EINVAL ;u16 len;trace_cdnsp_ctrl_req (ctrl);
@@ -424,7 +424,6 @@ void cdnsp_setup_analyze(struct cdnsp_deif (pdev->gadget.state ==USB_STATE_NOTATTACHED ) {dev_err (pdev->dev,"ERR: Setup detected in unattached state\n" ); - ret = -EINVAL ; goto out; }
Greg Kroah-Hartman
maintainerPATCH 54/93 usb: dwc3: pci: add support for the Intel Meteor Lake-S
In reply to Greg Kroah-HartmanFrom: Heikki Krogerus <[email protected]>
commit ec799c8a92e0be91e0940cc739a27f483242df65 upstream.
This patch adds the necessary PCI ID for Intel Meteor Lake-S devices.
--- drivers/usb/dwc3/dwc3-pci.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/dwc3/dwc3-pci.c +4 -0
@@ -47,6 +47,7 @@#define PCI_DEVICE_ID_INTEL_RPLS 0x7a61#define PCI_DEVICE_ID_INTEL_MTLM 0x7eb1#define PCI_DEVICE_ID_INTEL_MTLP 0x7ec1 +#define PCI_DEVICE_ID_INTEL_MTLS 0x7f6f#define PCI_DEVICE_ID_INTEL_MTL 0x7e7e#define PCI_DEVICE_ID_INTEL_TGL 0x9a15#define PCI_DEVICE_ID_AMD_MR 0x163a
@@ -434,6 +435,9 @@ static const struct pci_device_id dwc3_p {PCI_VDEVICE (INTEL ,PCI_DEVICE_ID_INTEL_MTLP ), (kernel_ulong_t) &dwc3_pci_intel_swnode, }, + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MTLS), + (kernel_ulong_t) &dwc3_pci_intel_swnode, }, + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MTL), (kernel_ulong_t) &dwc3_pci_intel_swnode, },
Greg Kroah-Hartman
maintainerPATCH 55/93 USB: serial: cp210x: add Silicon Labs IFS-USB-DATACABLE IDs
In reply to Greg Kroah-HartmanFrom: Kees Jan Koster <[email protected]>
commit 71f8afa2b66e356f435b6141b4a9ccf953e18356 upstream.
The Silicon Labs IFS-USB-DATACABLE is used in conjunction with for example the Quint UPSes. It is used to enable Modbus communication with the UPS to query configuration, power and battery status.
--- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/serial/cp210x.c +1 -0
@@ -120,6 +120,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(0x10C4, 0x826B) }, /* Cygnal Integrated Products, Inc., Fasttrax GPS demonstration module */ { USB_DEVICE(0x10C4, 0x8281) }, /* Nanotec Plug & Drive */ { USB_DEVICE(0x10C4, 0x8293) }, /* Telegesis ETRX2USB */ + { USB_DEVICE(0x10C4, 0x82AA) }, /* Silicon Labs IFS-USB-DATACABLE used with Quint UPS */ { USB_DEVICE(0x10C4, 0x82EF) }, /* CESINEL FALCO 6105 AC Power Supply */ { USB_DEVICE(0x10C4, 0x82F1) }, /* CESINEL MEDCAL EFD Earth Fault Detector */ { USB_DEVICE(0x10C4, 0x82F2) }, /* CESINEL MEDCAL ST Network Analyzer */
Greg Kroah-Hartman
maintainerPATCH 56/93 usb: typec: altmodes/displayport: Fix configure initial pin assignment
In reply to Greg Kroah-HartmanFrom: RD Babiera <[email protected]>
commit eddebe39602efe631b83ff8d03f26eba12cfd760 upstream.
While determining the initial pin assignment to be sent in the configure message, using the DP_PIN_ASSIGN_DP_ONLY_MASK mask causes the DFP_U to send both Pin Assignment C and E when both are supported by the DFP_U and UFP_U. The spec (Table 5-7 DFP_U Pin Assignment Selection Mandates, VESA DisplayPort Alt Mode Standard v2.0) indicates that the DFP_U never selects Pin Assignment E when Pin Assignment C is offered.
Update the DP_PIN_ASSIGN_DP_ONLY_MASK conditional to intially select only Pin Assignment C if it is available.
--- drivers/usb/typec/altmodes/displayport.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/usb/typec/altmodes/displayport.c +5 -1
@@ -101,8 +101,12 @@ static int dp_altmode_configure(struct dif (dp->data.status &DP_STATUS_PREFER_MULTI_FUNC && pin_assign &DP_PIN_ASSIGN_MULTI_FUNC_MASK ) pin_assign &=DP_PIN_ASSIGN_MULTI_FUNC_MASK ; -else if (pin_assign &DP_PIN_ASSIGN_DP_ONLY_MASK ) +else if (pin_assign &DP_PIN_ASSIGN_DP_ONLY_MASK ) { pin_assign &=DP_PIN_ASSIGN_DP_ONLY_MASK ; +/* Default to pin assign C if available */ +if (pin_assign &BIT (DP_PIN_ASSIGN_C )) + pin_assign =BIT (DP_PIN_ASSIGN_C ); + }if (!pin_assign)return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 57/93 USB: serial: option: add Telit FE990 compositions
In reply to Greg Kroah-HartmanFrom: Enrico Sau <[email protected]>
commit 773e8e7d07b753474b2ccd605ff092faaa9e65b9 upstream.
Add the following Telit FE990 compositions:
0x1080: tty, adb, rmnet, tty, tty, tty, tty 0x1081: tty, adb, mbim, tty, tty, tty, tty 0x1082: rndis, tty, adb, tty, tty, tty, tty 0x1083: tty, adb, ecm, tty, tty, tty, tty
--- drivers/usb/serial/option.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/usb/serial/option.c +8 -0
@@ -1300,6 +1300,14 @@ static const struct usb_device_id option .driver_info = NCTRL(0) | RSVD(1) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1075, 0xff), /* Telit FN990 (PCIe) */ .driver_info = RSVD(0) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1080, 0xff), /* Telit FE990 (rmnet) */ + .driver_info = NCTRL(0) | RSVD(1) | RSVD(2) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1081, 0xff), /* Telit FE990 (MBIM) */ + .driver_info = NCTRL(0) | RSVD(1) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1082, 0xff), /* Telit FE990 (RNDIS) */ + .driver_info = NCTRL(2) | RSVD(3) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1083, 0xff), /* Telit FE990 (ECM) */ + .driver_info = NCTRL(0) | RSVD(1) }, { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910), .driver_info = NCTRL(0) | RSVD(1) | RSVD(3) }, { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM),
Greg Kroah-Hartman
maintainerPATCH 58/93 USB: serial: option: add Quectel RM500U-CN modem
In reply to Greg Kroah-HartmanFrom: Bjørn Mork <[email protected]>
commit 7708a3858e69db91a8b69487994f33b96d20192a upstream.
This modem supports several modes with a class network function and a number of serial functions, all using ff/00/00
The device ID is the same in all modes.
RNDIS mode
----------
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0900 Rev= 4.04 S: Manufacturer=Quectel S: Product=RM500U-CN S: SerialNumber=0123456789ABCDEF
C:* #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
I:* If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
ECM mode
--------
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0900 Rev= 4.04 S: Manufacturer=Quectel S: Product=RM500U-CN S: SerialNumber=0123456789ABCDEF C:* #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
NCM mode
--------
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0900 Rev= 4.04 S: Manufacturer=Quectel S: Product=RM500U-CN S: SerialNumber=0123456789ABCDEF C:* #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_ncm E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
--- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -1198,6 +1198,8 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RM520N, 0xff, 0xff, 0x30) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RM520N, 0xff, 0, 0x40) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RM520N, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, 0x0900, 0xff, 0, 0), /* RM500U-CN */ + .driver_info = ZLP }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC200U, 0xff, 0, 0) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC200S_CN, 0xff, 0, 0) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC200T, 0xff, 0, 0) },
Greg Kroah-Hartman
maintainerPATCH 59/93 iio: adis16480: select CONFIG_CRC32
In reply to Greg Kroah-HartmanFrom: Arnd Bergmann <[email protected]>
commit d9b540ee461cca7edca0dd2c2a42625c6b9ffb8f upstream.
In rare randconfig builds, the missing CRC32 helper causes a link error:
ld.lld: error: undefined symbol: crc32_le
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
referenced by
usercopy_64.cvmlinux.o:(adis16480_trigger_handler)
--- drivers/iio/imu/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/iio/imu/Kconfig +1 -0
@@ -47,6 +47,7 @@ config ADIS16480 depends on SPI select IIO_ADIS_LIB select IIO_ADIS_LIB_BUFFER if IIO_BUFFER + select CRC32 help Say yes here to build support for Analog Devices ADIS16375, ADIS16480, ADIS16485, ADIS16488 inertial sensors.
Signature · 1 line
2.40.0
Greg Kroah-Hartman
maintainerPATCH 60/93 iio: adc: ti-ads7950: Set `can_sleep` flag for GPIO chip
In reply to Greg Kroah-HartmanFrom: Lars-Peter Clausen <[email protected]>
commit 363c7dc72f79edd55bf1c4380e0fbf7f1bbc2c86 upstream.
The ads7950 uses a mutex as well as SPI transfers in its GPIO callbacks. This means these callbacks can sleep and the can_sleep flag should be set.
Having the flag set will make sure that warnings are generated when calling any of the callbacks from a potentially non-sleeping context.
--- drivers/iio/adc/ti-ads7950.c | 1 + 1 file changed, 1 insertion(+)
drivers/iio/adc/ti-ads7950.c +1 -0
@@ -634,6 +634,7 @@ static int ti_ads7950_probe(struct spi_d st->chip.label =dev_name (&st->spi->dev); st->chip.parent = &st->spi->dev; st->chip.owner =THIS_MODULE ; + st->chip.can_sleep = true; st->chip.base =-1 ; st->chip.ngpio =TI_ADS7950_NUM_GPIOS ; st->chip.get_direction = ti_ads7950_get_direction;
Greg Kroah-Hartman
maintainerPATCH 61/93 iio: dac: cio-dac: Fix max DAC write value check for 12-bit
In reply to Greg Kroah-HartmanFrom: William Breathitt Gray <[email protected]>
commit c3701185ee1973845db088d8b0fc443397ab0eb2 upstream.
The CIO-DAC series of devices only supports DAC values up to 12-bit rather than 16-bit. Trying to write a 16-bit value results in only the lower 12 bits affecting the DAC output which is not what the user expects. Instead, adjust the DAC write value check to reject values larger than 12-bit so that they fail explicitly as invalid for the user.
--- drivers/iio/dac/cio-dac.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/iio/dac/cio-dac.c +2 -2
@@ -66,8 +66,8 @@ static int cio_dac_write_raw(struct iio_if (mask !=IIO_CHAN_INFO_RAW )return -EINVAL ; -/* DAC can only accept up to a 16-bit value */ -if ((unsigned int )val >65535 ) +/* DAC can only accept up to a 12-bit value */ +if ((unsigned int )val >4095 )return -EINVAL ; priv->chan_out_states[chan->channel] = val;
Greg Kroah-Hartman
maintainerPATCH 62/93 iio: light: cm32181: Unregister second I2C client if present
In reply to Greg Kroah-HartmanFrom: Kai-Heng Feng <[email protected]>
commit 099cc90a5a62e68b2fe3a42da011ab929b98bf73 upstream.
If a second dummy client that talks to the actual I2C address was created in probe(), there should be a proper cleanup on driver and device removal to avoid leakage.
So unregister the dummy client via another callback.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2152281
--- drivers/iio/light/cm32181.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/iio/light/cm32181.c +12 -0
@@ -429,6 +429,14 @@ static const struct iio_info cm32181_inf .attrs = &cm32181_attribute_group, }; +static void cm32181_unregister_dummy_client (void *data) +{ +struct i2c_client *client = data; + +/* Unregister the dummy client */ +i2c_unregister_device (client); +} +static int cm32181_probe (struct i2c_client *client) {struct device *dev = &client->dev;
@@ -458,6 +466,10 @@ static int cm32181_probe(struct i2c_clie client =i2c_acpi_new_device (dev,1 , &board_info);if (IS_ERR (client))return PTR_ERR (client); + + ret =devm_add_action_or_reset (dev, cm32181_unregister_dummy_client, client); +if (ret) +return ret; } cm32181 =iio_priv (indio_dev);
Greg Kroah-Hartman
maintainerPATCH 63/93 tty: serial: sh-sci: Fix transmit end interrupt handler
In reply to Greg Kroah-HartmanFrom: Biju Das <[email protected]>
commit b43a18647f03c87e77d50d6fe74904b61b96323e upstream.
The fourth interrupt on SCI port is transmit end interrupt compared to the break interrupt on other port types. So, shuffle the interrupts to fix the transmit end interrupt handler.
--- drivers/tty/serial/sh-sci.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/tty/serial/sh-sci.c +8 -0
@@ -31,6 +31,7 @@#include <linux/ioport.h> #include <linux/ktime.h> #include <linux/major.h> +#include <linux/minmax.h> #include <linux/module.h> #include <linux/mm.h> #include <linux/of.h>
@@ -2895,6 +2896,13 @@ static int sci_init_single(struct platfo sci_port->irqs[i] =platform_get_irq (dev, i); } +/* +* The fourth interrupt on SCI port is transmit end interrupt, so +* shuffle the interrupts. +*/ +if (p->type ==PORT_SCI ) +swap (sci_port->irqs[SCIx_BRI_IRQ], sci_port->irqs[SCIx_TEI_IRQ]); +/* The SCI generates several interrupts. They can be muxed together or * connected to different interrupt lines. In the muxed case only one * interrupt resource is specified as there is only one interrupt ID.
Greg Kroah-Hartman
maintainerPATCH 64/93 tty: serial: sh-sci: Fix Rx on RZ/G2L SCI
In reply to Greg Kroah-HartmanFrom: Biju Das <[email protected]>
commit f92ed0cd9328aed918ebb0ebb64d259eccbcc6e7 upstream.
SCI IP on RZ/G2L alike SoCs do not need regshift compared to other SCI IPs on the SH platform. Currently, it does regshift and configuring Rx wrongly. Drop adding regshift for RZ/G2L alike SoCs.
--- drivers/tty/serial/sh-sci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/serial/sh-sci.c +1 -1
@@ -2968,7 +2968,7 @@ static int sci_init_single(struct platfo port->flags =UPF_FIXED_PORT |UPF_BOOT_AUTOCONF | p->flags; port->fifosize = sci_port->params->fifosize; -if (port->type ==PORT_SCI ) { +if (port->type ==PORT_SCI && !dev->dev.of_node) {if (sci_port->reg_size >=0x20 ) port->regshift =2 ;else
Greg Kroah-Hartman
maintainerPATCH 65/93 tty: serial: fsl_lpuart: avoid checking for transfer complete when UARTCTRL_SBK is asserted in lpuart32_tx_empty
In reply to Greg Kroah-HartmanFrom: Sherry Sun <[email protected]>
commit 9425914f3de6febbd6250395f56c8279676d9c3c upstream.
According to LPUART RM, Transmission Complete Flag becomes 0 if queuing a break character by writing 1 to CTRL[SBK], so here need to avoid checking for transmission complete when UARTCTRL_SBK is asserted, otherwise the lpuart32_tx_empty may never get TIOCSER_TEMT.
Commit 2411fd94ceaa("tty: serial: fsl_lpuart: skip waiting for transmission complete when UARTCTRL_SBK is asserted") only fix it in lpuart32_set_termios(), here also fix it in lpuart32_tx_empty().
--- drivers/tty/serial/fsl_lpuart.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/tty/serial/fsl_lpuart.c +7 -1
@@ -829,11 +829,17 @@ static unsigned int lpuart32_tx_empty(st struct lpuart_port, port);unsigned long stat =lpuart32_read (port,UARTSTAT );unsigned long sfifo =lpuart32_read (port,UARTFIFO ); +unsigned long ctrl =lpuart32_read (port,UARTCTRL );if (sport->dma_tx_in_progress)return 0 ; -if (stat &UARTSTAT_TC && sfifo &UARTFIFO_TXEMPT ) +/* +* LPUART Transmission Complete Flag may never be set while queuing a break +* character, so avoid checking for transmission complete when UARTCTRL_SBK +* is asserted. +*/ +if ((stat &UARTSTAT_TC && sfifo &UARTFIFO_TXEMPT ) || ctrl &UARTCTRL_SBK )return TIOCSER_TEMT ;return 0 ;
Greg Kroah-Hartman
maintainerPATCH 66/93 nilfs2: fix potential UAF of struct nilfs_sc_info in nilfs_segctor_thread()
In reply to Greg Kroah-HartmanFrom: Ryusuke Konishi <[email protected]>
commit 6be49d100c22ffea3287a4b19d7639d259888e33 upstream.
The finalization of nilfs_segctor_thread() can race with nilfs_segctor_kill_thread() which terminates that thread, potentially causing a use-after-free BUG as KASAN detected.
At the end of nilfs_segctor_thread(), it assigns NULL to "sc_task" member of "struct nilfs_sc_info" to indicate the thread has finished, and then notifies nilfs_segctor_kill_thread() of this using waitqueue "sc_wait_task" on the struct nilfs_sc_info.
However, here, immediately after the NULL assignment to "sc_task", it is possible that nilfs_segctor_kill_thread() will detect it and return to continue the deallocation, freeing the nilfs_sc_info structure before the thread does the notification.
This fixes the issue by protecting the NULL assignment to "sc_task" and its notification, with spinlock "sc_state_lock" of the struct nilfs_sc_info. Since nilfs_segctor_kill_thread() does a final check to see if "sc_task" is NULL with "sc_state_lock" locked, this can eliminate the race.
--- fs/nilfs2/segment.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/nilfs2/segment.c +1 -2
@@ -2609,11 +2609,10 @@ static int nilfs_segctor_thread(void *ar goto loop; end_thread: -spin_unlock (&sci->sc_state_lock); -/* end sync. */ sci->sc_task =NULL ;wake_up (&sci->sc_wait_task);/* for nilfs_segctor_kill_thread() */ +spin_unlock (&sci->sc_state_lock);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 67/93 nilfs2: fix sysfs interface lifetime
In reply to Greg Kroah-HartmanFrom: Ryusuke Konishi <[email protected]>
commit 42560f9c92cc43dce75dbf06cc0d840dced39b12 upstream.
The current nilfs2 sysfs support has issues with the timing of creation and deletion of sysfs entries, potentially leading to null pointer dereferences, use-after-free, and lockdep warnings.
Some of the sysfs attributes for nilfs2 per-filesystem instance refer to metadata file "cpfile", "sufile", or "dat", but nilfs_sysfs_create_device_group that creates those attributes is executed before the inodes for these metadata files are loaded, and nilfs_sysfs_delete_device_group which deletes these sysfs entries is called after releasing their metadata file inodes.
Therefore, access to some of these sysfs attributes may occur outside of the lifetime of these metadata files, resulting in inode NULL pointer dereferences or use-after-free.
In addition, the call to nilfs_sysfs_create_device_group() is made during the locking period of the semaphore "ns_sem" of nilfs object, so the shrinker call caused by the memory allocation for the sysfs entries, may derive lock dependencies "ns_sem" -> (shrinker) -> "locks acquired in nilfs_evict_inode()".
Since nilfs2 may acquire "ns_sem" deep in the call stack holding other locks via its error handler __nilfs_error(), this causes lockdep to report circular locking. This is a false positive and no circular locking actually occurs as no inodes exist yet when nilfs_sysfs_create_device_group() is called. Fortunately, the lockdep warnings can be resolved by simply moving the call to nilfs_sysfs_create_device_group() out of "ns_sem".
This fixes these sysfs issues by revising where the device's sysfs interface is created/deleted and keeping its lifetime within the lifetime of the metadata files above.
--- fs/nilfs2/super.c | 2 ++ fs/nilfs2/the_nilfs.c | 12 +++++++----- 2 files changed, 9 insertions(+), 5 deletions(-)
fs/nilfs2/super.c +2 -0
@@ -482,6 +482,7 @@ static void nilfs_put_super(struct superup_write (&nilfs->ns_sem); } +nilfs_sysfs_delete_device_group (nilfs);iput (nilfs->ns_sufile);iput (nilfs->ns_cpfile);iput (nilfs->ns_dat);
@@ -1105,6 +1106,7 @@ nilfs_fill_super(struct super_block *sb,nilfs_put_root (fsroot); failed_unload: +nilfs_sysfs_delete_device_group (nilfs);iput (nilfs->ns_sufile);iput (nilfs->ns_cpfile);iput (nilfs->ns_dat);
fs/nilfs2/the_nilfs.c +7 -5
@@ -87,7 +87,6 @@ void destroy_nilfs(struct the_nilfs *nil {might_sleep ();if (nilfs_init (nilfs)) { -nilfs_sysfs_delete_device_group (nilfs);brelse (nilfs->ns_sbh[0 ]);brelse (nilfs->ns_sbh[1 ]); }
@@ -305,6 +304,10 @@ int load_nilfs(struct the_nilfs *nilfs, goto failed; } + err =nilfs_sysfs_create_device_group (sb); +if (unlikely (err)) + goto sysfs_error; +if (valid_fs) goto skip_recovery;
@@ -366,6 +369,9 @@ int load_nilfs(struct the_nilfs *nilfs, goto failed; failed_unload: +nilfs_sysfs_delete_device_group (nilfs); + + sysfs_error:iput (nilfs->ns_cpfile);iput (nilfs->ns_sufile);iput (nilfs->ns_dat);
@@ -697,10 +703,6 @@ int init_nilfs(struct the_nilfs *nilfs,if (err) goto failed_sbh; - err =nilfs_sysfs_create_device_group (sb); -if (err) - goto failed_sbh; -set_nilfs_init (nilfs); err =0 ; out:
Greg Kroah-Hartman
maintainerPATCH 68/93 dt-bindings: serial: renesas,scif: Fix 4th IRQ for 4-IRQ SCIFs
In reply to Greg Kroah-HartmanFrom: Geert Uytterhoeven <[email protected]>
commit 7b21f329ae0ab6361c0aebfc094db95821490cd1 upstream.
The fourth interrupt on SCIF variants with four interrupts (RZ/A1) is the Break interrupt, not the Transmit End interrupt (like on SCI(g)). Update the description and interrupt name to fix this.
--- Documentation/devicetree/bindings/serial/renesas,scif.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/serial/renesas,scif.yaml +2 -2
@@ -79,7 +79,7 @@ properties: - description: Error interrupt - description: Receive buffer full interrupt - description: Transmit buffer empty interrupt - - description: Transmit End interrupt + - description: Break interrupt - items: - description: Error interrupt - description: Receive buffer full interrupt
@@ -94,7 +94,7 @@ properties: - const: eri - const: rxi - const: txi - - const: tei + - const: bri - items: - const: eri - const: rxi
Greg Kroah-Hartman
maintainerPATCH 69/93 ksmbd: do not call kvmalloc() with __GFP_NORETRY | __GFP_NO_WARN
In reply to Greg Kroah-HartmanFrom: Marios Makassikis <[email protected]>
commit e416ea62a9166e6075a07a970cc5bf79255d2700 upstream.
Commit 83dcedd5540d ("ksmbd: fix infinite loop in ksmbd_conn_handler_loop()"), changes GFP modifiers passed to kvmalloc(). This cause xfstests generic/551 test to fail. We limit pdu length size according to connection status and maximum number of connections. In the rest, memory allocation of request is limited by credit management. so these flags are no longer needed.
--- fs/ksmbd/connection.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
fs/ksmbd/connection.c +1 -4
@@ -320,10 +320,7 @@ int ksmbd_conn_handler_loop(void *p)/* 4 for rfc1002 length field */ size = pdu_size +4 ; - conn->request_buf =kvmalloc (size, -GFP_KERNEL | - __GFP_NOWARN | - __GFP_NORETRY); + conn->request_buf =kvmalloc (size,GFP_KERNEL );if (!conn->request_buf)break ;
Greg Kroah-Hartman
maintainerPATCH 70/93 ALSA: hda/realtek: Add quirk for Clevo X370SNW
In reply to Greg Kroah-HartmanFrom: Jeremy Soller <[email protected]>
commit 36d4d213c6d4fffae2645a601e8ae996de4c3645 upstream.
Fixes speaker output and headset detection on Clevo X370SNW.
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -2618,6 +2618,7 @@ static const struct snd_pci_quirk alc882SND_PCI_QUIRK (0x1462 ,0xda57 ,"MSI Z270-Gaming" ,ALC1220_FIXUP_GB_DUAL_CODECS ),SND_PCI_QUIRK_VENDOR (0x1462 ,"MSI" ,ALC882_FIXUP_GPIO3 ),SND_PCI_QUIRK (0x147b ,0x107a ,"Abit AW9D-MAX" ,ALC882_FIXUP_ABIT_AW9D_MAX ), +SND_PCI_QUIRK (0x1558 ,0x3702 ,"Clevo X370SN[VW]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ),SND_PCI_QUIRK (0x1558 ,0x50d3 ,"Clevo PC50[ER][CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ),SND_PCI_QUIRK (0x1558 ,0x65d1 ,"Clevo PB51[ER][CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ), SND_PCI_QUIRK(0x1558, 0x65d2, "Clevo PB51R[CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
Greg Kroah-Hartman
maintainerPATCH 71/93 coresight: etm4x: Do not access TRCIDR1 for identification
In reply to Greg Kroah-HartmanFrom: Suzuki K Poulose <[email protected]>
commit 735e7b30a53a1679c050cddb73f5e5316105d2e3 upstream.
CoreSight ETM4x architecture clearly provides ways to identify a device via registers in the "Management" class, TRCDEVARCH and TRCDEVTYPE. These registers can be accessed without the Trace domain being powered on. We additionally added TRCIDR1 as fallback in order to cover for any ETMs that may not have implemented TRCDEVARCH. So far, nobody has reported hitting a WARNING we placed to catch such systems.
Also, more importantly it is problematic to access TRCIDR1, which is a "Trace" register via MMIO access, without clearing the OSLK. But we cannot mess with the OSLK until we know for sure that this is an ETMv4 device. Thus, this kind of creates a chicken and egg problem unnecessarily for systems "which are compliant" to the ETMv4 architecture.
Let us remove the TRCIDR1 fall back check and rely only on TRCDEVARCH.
--- drivers/hwtracing/coresight/coresight-etm4x-core.c | 22 ++++++++------------- drivers/hwtracing/coresight/coresight-etm4x.h | 20 +++++-------------- 2 files changed, 15 insertions(+), 27 deletions(-)
drivers/hwtracing/coresight/coresight-etm4x-core.c +9 -13
@@ -951,25 +951,21 @@ static bool etm4_init_iomem_access(struc struct csdev_access *csa) {u32 devarch =readl_relaxed (drvdata->base +TRCDEVARCH ); -u32 idr1 =readl_relaxed (drvdata->base +TRCIDR1 );/* * All ETMs must implement TRCDEVARCH to indicate that -* the component is an ETMv4. To support any broken -* implementations we fall back to TRCIDR1 check, which -* is not really reliable. +* the component is an ETMv4. Even though TRCIDR1 also +* contains the information, it is part of the "Trace" +* register and must be accessed with the OSLK cleared, +* with MMIO. But we cannot touch the OSLK until we are +* sure this is an ETM. So rely only on the TRCDEVARCH. */ -if ((devarch &ETM_DEVARCH_ID_MASK ) == ETM_DEVARCH_ETMv4x_ARCH) { - drvdata->arch =etm_devarch_to_arch (devarch); - }else { -pr_warn ("CPU%d: ETM4x incompatible TRCDEVARCH: %x, falling back to TRCIDR1\n" , -smp_processor_id (), devarch); - -if (ETM_TRCIDR1_ARCH_MAJOR (idr1) != ETM_TRCIDR1_ARCH_ETMv4) -return false; - drvdata->arch =etm_trcidr_to_arch (idr1); +if ((devarch &ETM_DEVARCH_ID_MASK ) != ETM_DEVARCH_ETMv4x_ARCH) { +pr_warn_once ("TRCDEVARCH doesn't match ETMv4 architecture\n" ); +return false; } + drvdata->arch =etm_devarch_to_arch (devarch); *csa =CSDEV_ACCESS_IOMEM (drvdata->base);return true; }
drivers/hwtracing/coresight/coresight-etm4x.h +6 -14
@@ -669,14 +669,12 @@* TRCDEVARCH - CoreSight architected register * - Bits[15:12] - Major version * - Bits[19:16] - Minor version -* TRCIDR1 - ETM architected register -* - Bits[11:8] - Major version -* - Bits[7:4] - Minor version -* We must rely on TRCDEVARCH for the version information, -* however we don't want to break the support for potential -* old implementations which might not implement it. Thus -* we fall back to TRCIDR1 if TRCDEVARCH is not implemented -* for memory mapped components. +* +* We must rely only on TRCDEVARCH for the version information. Even though, +* TRCIDR1 also provides the architecture version, it is a "Trace" register +* and as such must be accessed only with Trace power domain ON. This may +* not be available at probe time. +* * Now to make certain decisions easier based on the version * we use an internal representation of the version in the * driver, as follows :
@@ -702,12 +700,6 @@ static inline u8 etm_devarch_to_arch(u32 ETM_DEVARCH_REVISION(devarch)); } -static inline u8 etm_trcidr_to_arch (u32 trcidr1) -{ -return ETM_ARCH_VERSION (ETM_TRCIDR1_ARCH_MAJOR (trcidr1), -ETM_TRCIDR1_ARCH_MINOR (trcidr1)); -} -enum etm_impdef_type {ETM4_IMPDEF_HISI_CORE_COMMIT ,ETM4_IMPDEF_FEATURE_MAX ,
Greg Kroah-Hartman
maintainerPATCH 72/93 coresight-etm4: Fix for() loop drvdata->nr_addr_cmp range bug
In reply to Greg Kroah-HartmanFrom: Steve Clevenger <[email protected]>
commit bf84937e882009075f57fd213836256fc65d96bc upstream.
In etm4_enable_hw, fix for() loop range to represent address comparator pairs.
--- drivers/hwtracing/coresight/coresight-etm4x-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwtracing/coresight/coresight-etm4x-core.c +1 -1
@@ -411,7 +411,7 @@ static int etm4_enable_hw(struct etmv4_dif (etm4x_sspcicrn_present (drvdata, i))etm4x_relaxed_write32 (csa, config->ss_pe_cmp[i],TRCSSPCICRn (i)); } -for (i =0 ; i < drvdata->nr_addr_cmp; i++) { +for (i =0 ; i < drvdata->nr_addr_cmp *2 ; i++) {etm4x_relaxed_write64 (csa, config->addr_val[i],TRCACVRn (i));etm4x_relaxed_write64 (csa, config->addr_acc[i],TRCACATRn (i)); }
Greg Kroah-Hartman
maintainerPATCH 73/93 iio: adc: ad7791: fix IRQ flags
In reply to Greg Kroah-HartmanFrom: Nuno Sá <[email protected]>
[ Upstream commit 0c6ef985a1fd8a74dcb5cad941ddcadd55cb8697 ]
The interrupt is triggered on the falling edge rather than being a level low interrupt.
--- drivers/iio/adc/ad7791.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/adc/ad7791.c +1 -1
@@ -253,7 +253,7 @@ static const struct ad_sigma_delta_info ad7791_sigma_delta_info = { .has_registers = true, .addr_shift = 4, .read_mask = BIT(3), - .irq_flags = IRQF_TRIGGER_LOW, + .irq_flags = IRQF_TRIGGER_FALLING, }; static int ad7791_read_raw(struct iio_dev *indio_dev,
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 74/93 scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()
In reply to Greg Kroah-HartmanFrom: Li Zetao <[email protected]>
[ Upstream commit 85ade4010e13ef152ea925c74d94253db92e5428 ]
There is a memory leak reported by kmemleak:
unreferenced object 0xffffc900003f0000 (size 12288):
comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110
[<0000000001906886>] __vmalloc_node+0xbd/0x150
[<000000005bb4dc34>] vmalloc+0x25/0x30
[<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx]
[<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx]
[<00000000641ccc04>] local_pci_probe+0xeb/0x1a0The root cause is traced to an error-handling path in qla2x00_probe_one() when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" is used to record the port information and it is allocated in qla2x00_create_host(). However, it is not released in the error handling path "probe_failed".
Fix this by freeing the memory of "scan.l" when an error occurs in the adapter initialization process.
--- drivers/scsi/qla2xxx/qla_os.c | 1 + 1 file changed, 1 insertion(+)
drivers/scsi/qla2xxx/qla_os.c +1 -0
@@ -3573,6 +3573,7 @@ qla2x00_probe_one(struct pci_dev *pdev, const struct pci_device_id *id) probe_failed:qla_enode_stop (base_vha);qla_edb_stop (base_vha); +vfree (base_vha->scan.l);if (base_vha->gnl.l) {dma_free_coherent (&ha->pdev->dev, base_vha->gnl.size, base_vha->gnl.l, base_vha->gnl.ldma);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 75/93 scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param()
In reply to Greg Kroah-HartmanFrom: Zhong Jinghua <[email protected]>
[ Upstream commit 48b19b79cfa37b1e50da3b5a8af529f994c08901 ]
The validity of sock should be checked before assignment to avoid incorrect values. Commit 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()") introduced this change which may lead to inconsistent values of tcp_sw_conn->sendpage and conn->datadgst_en.
Fix the issue by moving the position of the assignment.
--- drivers/scsi/iscsi_tcp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/scsi/iscsi_tcp.c +1 -2
@@ -767,13 +767,12 @@ static int iscsi_sw_tcp_conn_set_param(struct iscsi_cls_conn *cls_conn,iscsi_set_param (cls_conn, param, buf, buflen);break ;case ISCSI_PARAM_DATADGST_EN : -iscsi_set_param (cls_conn, param, buf, buflen); -mutex_lock (&tcp_sw_conn->sock_lock);if (!tcp_sw_conn->sock) {mutex_unlock (&tcp_sw_conn->sock_lock);return -ENOTCONN ; } +iscsi_set_param (cls_conn, param, buf, buflen); tcp_sw_conn->sendpage = conn->datadgst_en ? sock_no_sendpage : tcp_sw_conn->sock->ops->sendpage;mutex_unlock (&tcp_sw_conn->sock_lock);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 76/93 smb3: allow deferred close timeout to be configurable
In reply to Greg Kroah-HartmanFrom: Steve French <[email protected]>
[ Upstream commit 5efdd9122eff772eae2feae9f0fc0ec02d4846a3 ]
Deferred close can be a very useful feature for allowing caching data for read, and for minimizing the number of reopens needed for a file that is repeatedly opened and close but there are workloads where its default (1 second, similar to actimeo/acregmax) is much too small.
Allow the user to configure the amount of time we can defer sending the final smb3 close when we have a handle lease on the file (rather than forcing it to depend on value of actimeo which is often unrelated, and less safe).
Adds new mount parameter "closetimeo=" which is the maximum number of seconds we can wait before sending an SMB3 close when we have a handle lease for it. Default value also is set to slightly larger at 5 seconds (although some other clients use larger default this should still help).
Stable-dep-of: d19342c6609b ("cifs: sanitize paths in cifs_update_super_prepath.")
--- fs/cifs/cifsfs.c | 1 + fs/cifs/connect.c | 2 ++ fs/cifs/file.c | 4 ++-- fs/cifs/fs_context.c | 9 +++++++++ fs/cifs/fs_context.h | 8 ++++++++ 5 files changed, 22 insertions(+), 2 deletions(-)
fs/cifs/cifsfs.c +1 -0
@@ -682,6 +682,7 @@ cifs_show_options(struct seq_file *s, struct dentry *root)seq_printf (s,",acdirmax=%lu" , cifs_sb->ctx->acdirmax /HZ );seq_printf (s,",acregmax=%lu" , cifs_sb->ctx->acregmax /HZ ); } +seq_printf (s,",closetimeo=%lu" , cifs_sb->ctx->closetimeo /HZ );if (tcon->ses->chan_max >1 ) seq_printf(s, ",multichannel,max_channels=%zu",
fs/cifs/connect.c +2 -0
@@ -2436,6 +2436,8 @@ compare_mount_options(struct super_block *sb, struct cifs_mnt_data *mnt_data)return 0 ;if (old->ctx->acdirmax != new->ctx->acdirmax)return 0 ; +if (old->ctx->closetimeo != new->ctx->closetimeo) +return 0 ;return 1 ; }
fs/cifs/file.c +2 -2
@@ -897,12 +897,12 @@ int cifs_close(struct inode *inode, struct file *file)* So, Increase the ref count to avoid use-after-free. */ if (!mod_delayed_work (deferredclose_wq, - &cfile->deferred, cifs_sb->ctx->acregmax)) + &cfile->deferred, cifs_sb->ctx->closetimeo))cifsFileInfo_get (cfile); }else {/* Deferred close for files */ queue_delayed_work (deferredclose_wq, - &cfile->deferred, cifs_sb->ctx->acregmax); + &cfile->deferred, cifs_sb->ctx->closetimeo); cfile->deferred_close_scheduled = true;spin_unlock (&cinode->deferred_lock);return 0 ;
fs/cifs/fs_context.c +9 -0
@@ -143,6 +143,7 @@ const struct fs_parameter_spec smb3_fs_parameters[] = {fsparam_u32 ("actimeo" , Opt_actimeo),fsparam_u32 ("acdirmax" , Opt_acdirmax),fsparam_u32 ("acregmax" , Opt_acregmax), +fsparam_u32 ("closetimeo" , Opt_closetimeo),fsparam_u32 ("echo_interval" , Opt_echo_interval),fsparam_u32 ("max_credits" , Opt_max_credits), fsparam_u32("handletimeout", Opt_handletimeout),
@@ -1058,6 +1059,13 @@ static int smb3_fs_context_parse_param(struct fs_context *fc, } ctx->acdirmax = ctx->acregmax =HZ * result.uint_32;break ; +case Opt_closetimeo: + ctx->closetimeo =HZ * result.uint_32; +if (ctx->closetimeo >SMB3_MAX_DCLOSETIMEO ) { +cifs_errorf (fc,"closetimeo too large\n" ); + goto cifs_parse_mount_err; + } +break ;case Opt_echo_interval: ctx->echo_interval = result.uint_32;break ;
@@ -1496,6 +1504,7 @@ int smb3_init_fs_context(struct fs_context *fc) ctx->acregmax =CIFS_DEF_ACTIMEO ; ctx->acdirmax =CIFS_DEF_ACTIMEO ; + ctx->closetimeo =SMB3_DEF_DCLOSETIMEO ;/* Most clients set timeout to 0, allows server to use its default */ ctx->handle_timeout =0 ;/* See MS-SMB2 spec section 2.2.14.2.12 */
fs/cifs/fs_context.h +8 -0
@@ -123,6 +123,7 @@ enum cifs_param { Opt_actimeo, Opt_acdirmax, Opt_acregmax, + Opt_closetimeo, Opt_echo_interval, Opt_max_credits, Opt_snapshot,
@@ -243,6 +244,8 @@ struct smb3_fs_context {/* attribute cache timemout for files and directories in jiffies */ unsigned long acregmax;unsigned long acdirmax; +/* timeout for deferred close of files in jiffies */ +unsigned long closetimeo;struct smb_version_operations *ops;struct smb_version_values *vals;char *prepath;
@@ -275,4 +278,9 @@ static inline struct smb3_fs_context *smb3_fc2context(const struct fs_context *fextern int smb3_fs_context_dup (struct smb3_fs_context *new_ctx,struct smb3_fs_context *ctx);extern void smb3_update_mnt_flags (struct cifs_sb_info *cifs_sb); +/* +* max deferred close timeout (jiffies) - 2^30 +*/ +#define SMB3_MAX_DCLOSETIMEO (1 << 30) +#define SMB3_DEF_DCLOSETIMEO (5 * HZ)/* Can increase later, other clients use larger */ #endif
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 77/93 smb3: lower default deferred close timeout to address perf regression
In reply to Greg Kroah-HartmanFrom: Steve French <[email protected]>
[ Upstream commit 7e0e76d99079be13c9961dde7c93b2d1ee665af4 ]
Performance tests with large number of threads noted that the change of the default closetimeo (deferred close timeout between when close is done by application and when client has to send the close to the server), to 5 seconds from 1 second, significantly degraded perf in some cases like this (in the filebench example reported, the stats show close requests on the wire taking twice as long, and 50% regression in filebench perf). This is stil configurable via mount parm closetimeo, but to be safe, decrease default back to its previous value of 1 second.
Stable-dep-of: d19342c6609b ("cifs: sanitize paths in cifs_update_super_prepath.")
--- fs/cifs/fs_context.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/cifs/fs_context.h +1 -1
@@ -282,5 +282,5 @@ extern void smb3_update_mnt_flags(struct cifs_sb_info *cifs_sb);* max deferred close timeout (jiffies) - 2^30 */ #define SMB3_MAX_DCLOSETIMEO (1 << 30) -#define SMB3_DEF_DCLOSETIMEO (5 * HZ)/* Can increase later, other clients use larger */ +#define SMB3_DEF_DCLOSETIMEO (1 * HZ)/* even 1 sec enough to help eg open/write/close/open/read */ #endif
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 78/93 cifs: sanitize paths in cifs_update_super_prepath.
In reply to Greg Kroah-HartmanFrom: Thiago Rafael Becker <[email protected]>
[ Upstream commit d19342c6609b67f2ba83b9eccca2777e3687f625 ]
After a server reboot, clients are failing to move files with ENOENT. This is caused by DFS referrals containing multiple separators, which the server move call doesn't recognize.
v1: Initial patch.
v2: Move prototype to header.
Actually-Fixes: 24e0a1eff9e2 ("cifs: switch to new mount api")
--- fs/cifs/fs_context.c | 13 +++++++------ fs/cifs/fs_context.h | 3 +++ fs/cifs/misc.c | 2 +- 3 files changed, 11 insertions(+), 7 deletions(-)
fs/cifs/fs_context.c +7 -6
@@ -437,13 +437,14 @@ int smb3_parse_opt(const char *options, const char *key, char **val)* but there are some bugs that prevent rename from working if there are * multiple delimiters. * -* Returns a sanitized duplicate of @path. The caller is responsible for -* cleaning up the original. +* Returns a sanitized duplicate of @path. @gfp indicates the GFP_* flags +* for kstrdup. +* The caller is responsible for freeing the original. */ #define IS_DELIM (c) ((c) == '/' || (c) == '\\') -static char *sanitize_path (char *path) +char *cifs_sanitize_prepath (char *prepath,gfp_t gfp) { -char *cursor1 = path, *cursor2 = path; +char *cursor1 = prepath, *cursor2 = prepath;/* skip all prepended delimiters */ while (IS_DELIM (*cursor1))
@@ -465,7 +466,7 @@ static char *sanitize_path(char *path) cursor2--; *(cursor2) ='\0' ; -return kstrdup (path,GFP_KERNEL ); +return kstrdup (prepath, gfp); }/*
@@ -527,7 +528,7 @@ smb3_parse_devname(const char *devname, struct smb3_fs_context *ctx)if (!*pos)return 0 ; - ctx->prepath =sanitize_path (pos); + ctx->prepath =cifs_sanitize_prepath (pos,GFP_KERNEL );if (!ctx->prepath)return -ENOMEM ;
fs/cifs/fs_context.h +3 -0
@@ -283,4 +283,7 @@ extern void smb3_update_mnt_flags(struct cifs_sb_info *cifs_sb);*/ #define SMB3_MAX_DCLOSETIMEO (1 << 30)#define SMB3_DEF_DCLOSETIMEO (1 * HZ)/* even 1 sec enough to help eg open/write/close/open/read */ + +extern char *cifs_sanitize_prepath (char *prepath,gfp_t gfp); +#endif
fs/cifs/misc.c +1 -1
@@ -1301,7 +1301,7 @@ int cifs_update_super_prepath(struct cifs_sb_info *cifs_sb, char *prefix)kfree (cifs_sb->prepath);if (prefix && *prefix) { - cifs_sb->prepath =kstrdup (prefix,GFP_ATOMIC ); + cifs_sb->prepath =cifs_sanitize_prepath (prefix,GFP_ATOMIC );if (!cifs_sb->prepath)return -ENOMEM ;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 79/93 perf/core: Fix the same task check in perf_event_set_output
In reply to Greg Kroah-HartmanFrom: Kan Liang <[email protected]>
[ Upstream commit 24d3ae2f37d8bc3c14b31d353c5d27baf582b6a6 ]
The same task check in perf_event_set_output has some potential issues for some usages.
For the current perf code, there is a problem if using of perf_event_open() to have multiple samples getting into the same mmap’d memory when they are both attached to the same process.
https://lore.kernel.org/all/[email protected]/
Because the event->ctx is not ready when the perf_event_set_output() is invoked in the perf_event_open().
Besides the above issue, before the commit bd2756811766 ("perf: Rewrite core context handling"), perf record can errors out when sampling with a hardware event and a software event as below.
$ perf record -e cycles,dummy --per-thread ls failed to mmap with 22 (Invalid argument) That's because that prior to the commit a hardware event and a software event are from different task context.
The problem should be a long time issue since commit c3f00c70276d ("perk: Separate find_get_context() from event initialization").
The task struct is stored in the event->hw.target for each per-thread event. It is a more reliable way to determine whether two events are attached to the same task.
The event->hw.target was also introduced several years ago by the commit 50f16a8bf9d7 ("perf: Remove type specific target pointers"). It can not only be used to fix the issue with the current code, but also back port to fix the issues with an older kernel.
Note: The event->hw.target was introduced later than commit c3f00c70276d. The patch may cannot be applied between the commit c3f00c70276d and commit 50f16a8bf9d7. Anybody that wants to back-port this at that period may have to find other solutions.
--- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/events/core.c +1 -1
@@ -12024,7 +12024,7 @@ perf_event_set_output(struct perf_event *event, struct perf_event *output_event)/* * If its not a per-cpu rb, it must be the same task. */ -if (output_event->cpu ==-1 && output_event->ctx != event->ctx) +if (output_event->cpu ==-1 && output_event->hw.target != event->hw.target) goto out;/*
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 80/93 ftrace: Mark get_lock_parent_ip() __always_inline
In reply to Greg Kroah-HartmanFrom: John Keeping <[email protected]>
commit ea65b41807a26495ff2a73dd8b1bab2751940887 upstream.
If the compiler decides not to inline this function then preemption tracing will always show an IP inside the preemption disabling path and never the function actually calling preempt_{enable,disable}.
--- include/linux/ftrace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/ftrace.h +1 -1
@@ -850,7 +850,7 @@ static inline void __ftrace_enabled_rest#define CALLER_ADDR5 ((unsigned long)ftrace_return_address(5))#define CALLER_ADDR6 ((unsigned long)ftrace_return_address(6)) -static inline unsigned long get_lock_parent_ip (void ) +static __always_inline unsigned long get_lock_parent_ip (void ) {unsigned long addr =CALLER_ADDR0 ;
Greg Kroah-Hartman
maintainerPATCH 81/93 ftrace: Fix issue that direct->addr not restored in modify_ftrace_direct()
In reply to Greg Kroah-HartmanFrom: Zheng Yejian <[email protected]>
commit 2a2d8c51defb446e8d89a83f42f8e5cd529111e9 upstream.
Syzkaller report a WARNING: "WARN_ON(!direct)" in modify_ftrace_direct().
Root cause is 'direct->addr' was changed from 'old_addr' to 'new_addr' but not restored if error happened on calling ftrace_modify_direct_caller(). Then it can no longer find 'direct' by that 'old_addr'.
To fix it, restore 'direct->addr' to 'old_addr' explicitly in error path.
--- kernel/trace/ftrace.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
kernel/trace/ftrace.c +9 -6
@@ -5383,12 +5383,15 @@ int modify_ftrace_direct(unsigned long i ret =0 ; } -if (unlikely (ret && new_direct)) { - direct->count++; -list_del_rcu (&new_direct->next); -synchronize_rcu_tasks (); -kfree (new_direct); - ftrace_direct_func_count--; +if (ret) { + direct->addr = old_addr; +if (unlikely (new_direct)) { + direct->count++; +list_del_rcu (&new_direct->next); +synchronize_rcu_tasks (); +kfree (new_direct); + ftrace_direct_func_count--; + } } out_unlock:
Greg Kroah-Hartman
maintainerPATCH 82/93 fs: drop peer group ids under namespace lock
In reply to Greg Kroah-HartmanFrom: Christian Brauner <[email protected]>
commit cb2239c198ad9fbd5aced22cf93e45562da781eb upstream.
When cleaning up peer group ids in the failure path we need to make sure to hold on to the namespace lock. Otherwise another thread might just turn the mount from a shared into a non-shared mount concurrently.
Message-Id: <20230330-vfs-mount_setattr-propagation-fix-v1-1-37548d91533b@kernel.org>
--- fs/namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/namespace.c +1 -1
@@ -4121,9 +4121,9 @@ static int do_mount_setattr(struct pathunlock_mount_hash ();if (kattr->propagation) { -namespace_unlock ();if (err)cleanup_group_ids (mnt,NULL ); +namespace_unlock (); }return err;
Greg Kroah-Hartman
maintainerPATCH 83/93 can: j1939: j1939_tp_tx_dat_new(): fix out-of-bounds memory access
In reply to Greg Kroah-HartmanFrom: Oleksij Rempel <[email protected]>
commit b45193cb4df556fe6251b285a5ce44046dd36b4a upstream.
In the j1939_tp_tx_dat_new() function, an out-of-bounds memory access could occur during the memcpy() operation if the size of skb->cb is larger than the size of struct j1939_sk_buff_cb. This is because the memcpy() operation uses the size of skb->cb, leading to a read beyond the struct j1939_sk_buff_cb.
Updated the memcpy() operation to use the size of struct j1939_sk_buff_cb instead of the size of skb->cb. This ensures that the memcpy() operation only reads the memory within the bounds of struct j1939_sk_buff_cb, preventing out-of-bounds memory access.
Additionally, add a BUILD_BUG_ON() to check that the size of skb->cb is greater than or equal to the size of struct j1939_sk_buff_cb. This ensures that the skb->cb buffer is large enough to hold the j1939_sk_buff_cb structure.
--- net/can/j1939/transport.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
net/can/j1939/transport.c +4 -1
@@ -604,7 +604,10 @@ sk_buff *j1939_tp_tx_dat_new(struct j193/* reserve CAN header */ skb_reserve (skb, offsetof(struct can_frame , data)); -memcpy (skb->cb, re_skcb,sizeof (skb->cb)); +/* skb->cb must be large enough to hold a j1939_sk_buff_cb structure */ +BUILD_BUG_ON (sizeof (skb->cb) <sizeof (*re_skcb)); + +memcpy (skb->cb, re_skcb,sizeof (*re_skcb)); skcb =j1939_skb_to_cb (skb);if (swap_src_dst)j1939_skbcb_swap (skcb);
Greg Kroah-Hartman
maintainerPATCH 84/93 can: isotp: isotp_ops: fix poll() to not report false EPOLLOUT events
In reply to Greg Kroah-HartmanFrom: Michal Sojka <[email protected]>
commit 79e19fa79cb5d5f1b3bf3e3ae24989ccb93c7b7b upstream.
When using select()/poll()/epoll() with a non-blocking ISOTP socket to wait for when non-blocking write is possible, a false EPOLLOUT event is sometimes returned. This can happen at least after sending a message which must be split to multiple CAN frames.
The reason is that isotp_sendmsg() returns -EAGAIN when tx.state is not equal to ISOTP_IDLE and this behavior is not reflected in datagram_poll(), which is used in isotp_ops.
This is fixed by introducing ISOTP-specific poll function, which suppresses the EPOLLOUT events in that case.
v2: https://lore.kernel.org/all/[email protected]
v1: https://lore.kernel.org/all/[email protected]
https://lore.kernel.org/all/[email protected]
--- net/can/isotp.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
net/can/isotp.c +16 -1
@@ -1482,6 +1482,21 @@ static int isotp_init(struct sock *sk)return 0 ; } +static __poll_t isotp_poll (struct file *file,struct socket *sock,poll_table *wait) +{ +struct sock *sk = sock->sk; +struct isotp_sock *so =isotp_sk (sk); + +__poll_t mask =datagram_poll (file, sock, wait); +poll_wait (file, &so->wait, wait); + +/* Check for false positives due to TX state */ +if ((mask &EPOLLWRNORM ) && (so->tx.state !=ISOTP_IDLE )) + mask &= ~(EPOLLOUT |EPOLLWRNORM ); + +return mask; +} +static int isotp_sock_no_ioctlcmd (struct socket *sock,unsigned int cmd,unsigned long arg) {
@@ -1497,7 +1512,7 @@ static const struct proto_ops isotp_ops .socketpair = sock_no_socketpair, .accept = sock_no_accept, .getname = isotp_getname, - .poll = datagram_poll, + .poll = isotp_poll, .ioctl = isotp_sock_no_ioctlcmd, .gettstamp = sock_gettstamp, .listen = sock_no_listen,
Greg Kroah-Hartman
maintainerPATCH 85/93 tracing: Free error logs of tracing instances
In reply to Greg Kroah-HartmanFrom: Steven Rostedt (Google) <[email protected]>
commit 3357c6e429643231e60447b52ffbb7ac895aca22 upstream.
When a tracing instance is removed, the error messages that hold errors that occurred in the instance needs to be freed. The following reports a memory leak:
# cd /sys/kernel/tracing
# mkdir instances/foo
# echo 'hist:keys=x' > instances/foo/events/sched/sched_switch/trigger
# cat instances/foo/error_log
[ 117.404795] hist:sched:sched_switch: error: Couldn't find field
Command: hist:keys=x
^
# rmdir instances/fooThen check for memory leaks:
# echo scan > /sys/kernel/debug/kmemleak
# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff88810d8ec700 (size 192):
comm "bash", pid 869, jiffies 4294950577 (age 215.752s)
hex dump (first 32 bytes):
60 dd 68 61 81 88 ff ff 60 dd 68 61 81 88 ff ff `.ha....`.ha....
a0 30 8c 83 ff ff ff ff 26 00 0a 00 00 00 00 00 .0......&.......
backtrace:
[<00000000dae26536>] kmalloc_trace+0x2a/0xa0
[<00000000b2938940>] tracing_log_err+0x277/0x2e0
[<000000004a0e1b07>] parse_atom+0x966/0xb40
[<0000000023b24337>] parse_expr+0x5f3/0xdb0
[<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560
[<00000000293a9645>] trigger_process_regex+0x135/0x1a0
[<000000005c22b4f2>] event_trigger_write+0x87/0xf0
[<000000002cadc509>] vfs_write+0x162/0x670
[<0000000059c3b9be>] ksys_write+0xca/0x170
[<00000000f1cddc00>] do_syscall_64+0x3e/0xc0
[<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
unreferenced object 0xffff888170c35a00 (size 32):
comm "bash", pid 869, jiffies 4294950577 (age 215.752s)
hex dump (first 32 bytes):
0a 20 20 43 6f 6d 6d 61 6e 64 3a 20 68 69 73 74 . Command: hist
3a 6b 65 79 73 3d 78 0a 00 00 00 00 00 00 00 00 :keys=x.........
backtrace:
[<000000006a747de5>] __kmalloc+0x4d/0x160
[<000000000039df5f>] tracing_log_err+0x29b/0x2e0
[<000000004a0e1b07>] parse_atom+0x966/0xb40
[<0000000023b24337>] parse_expr+0x5f3/0xdb0
[<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560
[<00000000293a9645>] trigger_process_regex+0x135/0x1a0
[<000000005c22b4f2>] event_trigger_write+0x87/0xf0
[<000000002cadc509>] vfs_write+0x162/0x670
[<0000000059c3b9be>] ksys_write+0xca/0x170
[<00000000f1cddc00>] do_syscall_64+0x3e/0xc0
[<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdcThe problem is that the error log needs to be freed when the instance is removed.
--- kernel/trace/trace.c | 1 + 1 file changed, 1 insertion(+)
kernel/trace/trace.c +1 -0
@@ -9416,6 +9416,7 @@ static int __remove_instance(struct tractracefs_remove (tr->dir);free_percpu (tr->last_func_repeats);free_trace_buffers (tr); +clear_tracing_err_log (tr);for (i =0 ; i < tr->nr_topts; i++) {kfree (tr->topts[i].topts);
Greg Kroah-Hartman
maintainerPATCH 86/93 ASoC: hdac_hdmi: use set_stream() instead of set_tdm_slots()
In reply to Greg Kroah-HartmanFrom: Jason Montleon <[email protected]>
commit f6887a71bdd2f0dcba9b8180dd2223cfa8637e85 upstream.
hdac_hdmi was not updated to use set_stream() instead of set_tdm_slots() in the original commit so HDMI no longer produces audio.
--- sound/soc/codecs/hdac_hdmi.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
sound/soc/codecs/hdac_hdmi.c +11 -6
@@ -436,23 +436,28 @@ static int hdac_hdmi_setup_audio_infofrareturn 0 ; } -static int hdac_hdmi_set_tdm_slot (struct snd_soc_dai *dai, -unsigned int tx_mask,unsigned int rx_mask, -int slots,int slot_width) +static int hdac_hdmi_set_stream (struct snd_soc_dai *dai, +void *stream,int direction) {struct hdac_hdmi_priv *hdmi =snd_soc_dai_get_drvdata (dai);struct hdac_device *hdev = hdmi->hdev;struct hdac_hdmi_dai_port_map *dai_map;struct hdac_hdmi_pcm *pcm; +struct hdac_stream *hstream; -dev_dbg (&hdev->dev,"%s: strm_tag: %d\n" , __func__, tx_mask); +if (!stream) +return -EINVAL ; + + hstream = (struct hdac_stream *)stream; + +dev_dbg (&hdev->dev,"%s: strm_tag: %d\n" , __func__, hstream->stream_tag); dai_map = &hdmi->dai_map[dai->id]; pcm =hdac_hdmi_get_pcm_from_cvt (hdmi, dai_map->cvt);if (pcm) - pcm->stream_tag = (tx_mask <<4 ); + pcm->stream_tag = (hstream->stream_tag <<4 );return 0 ; }
@@ -1544,7 +1549,7 @@ static const struct snd_soc_dai_ops hdmi .startup = hdac_hdmi_pcm_open, .shutdown = hdac_hdmi_pcm_close, .hw_params = hdac_hdmi_set_hw_params, - .set_tdm_slot = hdac_hdmi_set_tdm_slot, + .set_stream = hdac_hdmi_set_stream, };/*
Greg Kroah-Hartman
maintainerPATCH 87/93 mm: vmalloc: avoid warn_alloc noise caused by fatal signal
In reply to Greg Kroah-HartmanFrom: Yafang Shao <[email protected]>
commit f349b15e183d6956f1b63d6ff57849ff10c7edd5 upstream.
There're some suspicious warn_alloc on my test serer, for example,
[13366.518837] warn_alloc: 81 callbacks suppressed [13366.518841] test_verifier: vmalloc error: size 4096, page order 0, failed to allocate pages, mode:0x500dc2(GFP_HIGHUSER|__GFP_ZERO|__GFP_ACCOUNT), nodemask=(null),cpuset=/,mems_allowed=0-1 [13366.522240] CPU: 30 PID: 722463 Comm: test_verifier Kdump: loaded Tainted: G W O 6.2.0+ #638 [13366.524216] Call Trace: [13366.524702] <TASK> [13366.525148] dump_stack_lvl+0x6c/0x80 [13366.525712] dump_stack+0x10/0x20 [13366.526239] warn_alloc+0x119/0x190 [13366.526783] ? alloc_pages_bulk_array_mempolicy+0x9e/0x2a0 [13366.527470] __vmalloc_area_node+0x546/0x5b0 [13366.528066] __vmalloc_node_range+0xc2/0x210 [13366.528660] __vmalloc_node+0x42/0x50 [13366.529186] ? bpf_prog_realloc+0x53/0xc0 [13366.529743] __vmalloc+0x1e/0x30 [13366.530235] bpf_prog_realloc+0x53/0xc0 [13366.530771] bpf_patch_insn_single+0x80/0x1b0 [13366.531351] bpf_jit_blind_constants+0xe9/0x1c0 [13366.531932] ? __free_pages+0xee/0x100 [13366.532457] ? free_large_kmalloc+0x58/0xb0 [13366.533002] bpf_int_jit_compile+0x8c/0x5e0 [13366.533546] bpf_prog_select_runtime+0xb4/0x100 [13366.534108] bpf_prog_load+0x6b1/0xa50 [13366.534610] ? perf_event_task_tick+0x96/0xb0 [13366.535151] ? security_capable+0x3a/0x60 [13366.535663] __sys_bpf+0xb38/0x2190 [13366.536120] ? kvm_clock_get_cycles+0x9/0x10 [13366.536643] __x64_sys_bpf+0x1c/0x30 [13366.537094] do_syscall_64+0x38/0x90 [13366.537554] entry_SYSCALL_64_after_hwframe+0x72/0xdc [13366.538107] RIP: 0033:0x7f78310f8e29 [13366.538561] Code: 01 00 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 17 e0 2c 00 f7 d8 64 89 01 48 [13366.540286] RSP: 002b:00007ffe2a61fff8 EFLAGS: 00000206 ORIG_RAX: 0000000000000141 [13366.541031] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f78310f8e29 [13366.541749] RDX: 0000000000000080 RSI: 00007ffe2a6200b0 RDI: 0000000000000005 [13366.542470] RBP: 00007ffe2a620010 R08: 00007ffe2a6202a0 R09: 00007ffe2a6200b0 [13366.543183] R10: 00000000000f423e R11: 0000000000000206 R12: 0000000000407800 [13366.543900] R13: 00007ffe2a620540 R14: 0000000000000000 R15: 0000000000000000 [13366.544623] </TASK> [13366.545260] Mem-Info: [13366.546121] active_anon:81319 inactive_anon:20733 isolated_anon:0 active_file:69450 inactive_file:5624 isolated_file:0 unevictable:0 dirty:10 writeback:0 slab_reclaimable:69649 slab_unreclaimable:48930 mapped:27400 shmem:12868 pagetables:4929 sec_pagetables:0 bounce:0 kernel_misc_reclaimable:0 free:15870308 free_pcp:142935 free_cma:0 [13366.551886] Node 0 active_anon:224836kB inactive_anon:33528kB active_file:175692kB inactive_file:13752kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:59248kB dirty:32kB writeback:0kB shmem:18252kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB kernel_stack:4616kB pagetables:10664kB sec_pagetables:0kB all_unreclaimable? no [13366.555184] Node 1 active_anon:100440kB inactive_anon:49404kB active_file:102108kB inactive_file:8744kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:50352kB dirty:8kB writeback:0kB shmem:33220kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB kernel_stack:3896kB pagetables:9052kB sec_pagetables:0kB all_unreclaimable? no [13366.558262] Node 0 DMA free:15360kB boost:0kB min:304kB low:380kB high:456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [13366.560821] lowmem_reserve[]: 0 2735 31873 31873 31873 [13366.561981] Node 0 DMA32 free:2790904kB boost:0kB min:56028kB low:70032kB high:84036kB reserved_highatomic:0KB active_anon:1936kB inactive_anon:20kB active_file:396kB inactive_file:344kB unevictable:0kB writepending:0kB present:3129200kB managed:2801520kB mlocked:0kB bounce:0kB free_pcp:5188kB local_pcp:0kB free_cma:0kB [13366.565148] lowmem_reserve[]: 0 0 29137 29137 29137 [13366.566168] Node 0 Normal free:28533824kB boost:0kB min:596740kB low:745924kB high:895108kB reserved_highatomic:28672KB active_anon:222900kB inactive_anon:33508kB active_file:175296kB inactive_file:13408kB unevictable:0kB writepending:32kB present:30408704kB managed:29837172kB mlocked:0kB bounce:0kB free_pcp:295724kB local_pcp:0kB free_cma:0kB [13366.569485] lowmem_reserve[]: 0 0 0 0 0 [13366.570416] Node 1 Normal free:32141144kB boost:0kB min:660504kB low:825628kB high:990752kB reserved_highatomic:69632KB active_anon:100440kB inactive_anon:49404kB active_file:102108kB inactive_file:8744kB unevictable:0kB writepending:8kB present:33554432kB managed:33025372kB mlocked:0kB bounce:0kB free_pcp:270880kB local_pcp:46860kB free_cma:0kB [13366.573403] lowmem_reserve[]: 0 0 0 0 0 [13366.574015] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15360kB [13366.575474] Node 0 DMA32: 782*4kB (UME) 756*8kB (UME) 736*16kB (UME) 745*32kB (UME) 694*64kB (UME) 653*128kB (UME) 595*256kB (UME) 552*512kB (UME) 454*1024kB (UME) 347*2048kB (UME) 246*4096kB (UME) = 2790904kB [13366.577442] Node 0 Normal: 33856*4kB (UMEH) 51815*8kB (UMEH) 42418*16kB (UMEH) 36272*32kB (UMEH) 22195*64kB (UMEH) 10296*128kB (UMEH) 7238*256kB (UMEH) 5638*512kB (UEH) 5337*1024kB (UMEH) 3506*2048kB (UMEH) 1470*4096kB (UME) = 28533784kB [13366.580460] Node 1 Normal: 15776*4kB (UMEH) 37485*8kB (UMEH) 29509*16kB (UMEH) 21420*32kB (UMEH) 14818*64kB (UMEH) 13051*128kB (UMEH) 9918*256kB (UMEH) 7374*512kB (UMEH) 5397*1024kB (UMEH) 3887*2048kB (UMEH) 2002*4096kB (UME) = 32141240kB [13366.583027] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [13366.584380] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [13366.585702] Node 1 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [13366.587042] Node 1 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [13366.588372] 87386 total pagecache pages [13366.589266] 0 pages in swap cache [13366.590327] Free swap = 0kB [13366.591227] Total swap = 0kB [13366.592142] 16777082 pages RAM [13366.593057] 0 pages HighMem/MovableOnly [13366.594037] 357226 pages reserved [13366.594979] 0 pages hwpoisoned
This failure really confuse me as there're still lots of available pages. Finally I figured out it was caused by a fatal signal. When a process is allocating memory via vm_area_alloc_pages(), it will break directly even if it hasn't allocated the requested pages when it receives a fatal signal. In that case, we shouldn't show this warn_alloc, as it is useless. We only need to show this warning when there're really no enough pages.
--- mm/vmalloc.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
mm/vmalloc.c +5 -3
@@ -2927,9 +2927,11 @@ static void *__vmalloc_area_node(struct* allocation request, free them via __vfree() if any. */ if (area->nr_pages != nr_small_pages) { -warn_alloc (gfp_mask,NULL , -"vmalloc error: size %lu, page order %u, failed to allocate pages" , - area->nr_pages *PAGE_SIZE , page_order); +/* vm_area_alloc_pages() can also fail due to a fatal signal */ +if (!fatal_signal_pending (current)) +warn_alloc (gfp_mask,NULL , +"vmalloc error: size %lu, page order %u, failed to allocate pages" , + area->nr_pages *PAGE_SIZE , page_order); goto fail; }
Greg Kroah-Hartman
maintainerPATCH 88/93 drm/panfrost: Fix the panfrost_mmu_map_fault_addr() error path
In reply to Greg Kroah-HartmanFrom: Boris Brezillon <[email protected]>
commit 764a2ab9eb56e1200083e771aab16186836edf1d upstream.
Make sure all bo->base.pages entries are either NULL or pointing to a valid page before calling drm_gem_shmem_put_pages().
--- drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/panfrost/panfrost_mmu.c +1 -0
@@ -469,6 +469,7 @@ static int panfrost_mmu_map_fault_addr(sif (IS_ERR (pages[i])) {mutex_unlock (&bo->base.pages_lock); ret =PTR_ERR (pages[i]); + pages[i] =NULL ; goto err_pages; } }
Greg Kroah-Hartman
maintainerPATCH 89/93 drm/nouveau/disp: Support more modes by checking with lower bpc
In reply to Greg Kroah-HartmanFrom: Karol Herbst <[email protected]>
commit 7f67aa097e875c87fba024e850cf405342300059 upstream.
This allows us to advertise more modes especially on HDR displays.
Fixes using 4K@60 modes on my TV and main display both using a HDMI to DP adapter. Also fixes similar issues for users running into this.
--- drivers/gpu/drm/nouveau/dispnv50/disp.c | 32 ++++++++++++++++++++++++++++++++ drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +++++--- 2 files changed, 37 insertions(+), 3 deletions(-)
drivers/gpu/drm/nouveau/dispnv50/disp.c +32 -0
@@ -411,6 +411,35 @@ nv50_outp_atomic_check_view(struct drm_ereturn 0 ; } +static void +nv50_outp_atomic_fix_depth (struct drm_encoder *encoder,struct drm_crtc_state *crtc_state) +{ +struct nv50_head_atom *asyh =nv50_head_atom (crtc_state); +struct nouveau_encoder *nv_encoder =nouveau_encoder (encoder); +struct drm_display_mode *mode = &asyh->state.adjusted_mode; +unsigned int max_rate, mode_rate; + +switch (nv_encoder->dcb->type) { +case DCB_OUTPUT_DP : + max_rate = nv_encoder->dp.link_nr * nv_encoder->dp.link_bw; + +/* we don't support more than 10 anyway */ + asyh->or.bpc =min_t (u8, asyh->or.bpc,10 ); + +/* reduce the bpc until it works out */ +while (asyh->or.bpc >6 ) { + mode_rate =DIV_ROUND_UP (mode->clock * asyh->or.bpc *3 ,8 ); +if (mode_rate <= max_rate) +break ; + + asyh->or.bpc -=2 ; + } +break ; +default : +break ; + } +} + static int nv50_outp_atomic_check(struct drm_encoder *encoder, struct drm_crtc_state *crtc_state,
@@ -429,6 +458,9 @@ nv50_outp_atomic_check(struct drm_encodeif (crtc_state->mode_changed || crtc_state->connectors_changed) asyh->or.bpc = connector->display_info.bpc; +/* We might have to reduce the bpc */ +nv50_outp_atomic_fix_depth (encoder, crtc_state); +return 0 ; }
drivers/gpu/drm/nouveau/nouveau_dp.c +5 -3
@@ -220,8 +220,6 @@ void nouveau_dp_irq(struct nouveau_drm * }/* TODO: -* - Use the minimum possible BPC here, once we add support for the max bpc -* property. * - Validate against the DP caps advertised by the GPU (we don't check these * yet) */
@@ -233,7 +231,11 @@ nv50_dp_mode_valid(struct drm_connector {const unsigned int min_clock =25000 ;unsigned int max_rate, mode_rate, ds_max_dotclock, clock = mode->clock; -const u8 bpp = connector->display_info.bpc *3 ; +/* Check with the minmum bpc always, so we can advertise better modes. +* In particlar not doing this causes modes to be dropped on HDR +* displays as we might check with a bpc of 16 even. +*/ +const u8 bpp =6 *3 ;if (mode->flags &DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)return MODE_NO_INTERLACE ;
Greg Kroah-Hartman
maintainerPATCH 90/93 ring-buffer: Fix race while reader and writer are on the same page
In reply to Greg Kroah-HartmanFrom: Zheng Yejian <[email protected]>
commit 6455b6163d8c680366663cdb8c679514d55fc30c upstream.
When user reads file 'trace_pipe', kernel keeps printing following logs that warn at "cpu_buffer->reader_page->read > rb_page_size(reader)" in rb_get_reader_page(). It just looks like there's an infinite loop in tracing_read_pipe(). This problem occurs several times on arm64 platform when testing v5.10 and below.
Call trace: rb_get_reader_page+0x248/0x1300 rb_buffer_peek+0x34/0x160 ring_buffer_peek+0xbc/0x224 peek_next_entry+0x98/0xbc __find_next_entry+0xc4/0x1c0 trace_find_next_entry_inc+0x30/0x94 tracing_read_pipe+0x198/0x304 vfs_read+0xb4/0x1e0 ksys_read+0x74/0x100 __arm64_sys_read+0x24/0x30 el0_svc_common.constprop.0+0x7c/0x1bc do_el0_svc+0x2c/0x94 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180
Then I dump the vmcore and look into the problematic per_cpu ring_buffer, I found that tail_page/commit_page/reader_page are on the same page while reader_page->read is obviously abnormal:
tail_page == commit_page == reader_page == {
.write = 0x100d20,
.read = 0x8f9f4805, // Far greater than 0xd20, obviously abnormal!!!
.entries = 0x10004c,
.real_end = 0x0,
.page = {
.time_stamp = 0x857257416af0,
.commit = 0xd20, // This page hasn't been full filled.
// .data[0...0xd20] seems normal.
}}
The root cause is most likely the race that reader and writer are on the same page while reader saw an event that not fully committed by writer.
To fix this, add memory barriers to make sure the reader can see the content of what is committed. Since commit a0fcaaed0c46 ("ring-buffer: Fix race between reset page and reading page") has added the read barrier in rb_get_reader_page(), here we just need to add the write barrier.
--- kernel/trace/ring_buffer.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
kernel/trace/ring_buffer.c +12 -1
@@ -3041,6 +3041,10 @@ rb_set_commit_to_write(struct ring_buffeif (RB_WARN_ON (cpu_buffer,rb_is_reader_page (cpu_buffer->tail_page)))return ; +/* +* No need for a memory barrier here, as the update +* of the tail_page did it for this page. +*/ local_set (&cpu_buffer->commit_page->page->commit,rb_page_write (cpu_buffer->commit_page));rb_inc_page (&cpu_buffer->commit_page);
@@ -3050,6 +3054,8 @@ rb_set_commit_to_write(struct ring_buffewhile (rb_commit_index (cpu_buffer) !=rb_page_write (cpu_buffer->commit_page)) { +/* Make sure the readers see the content of what is committed. */ +smp_wmb ();local_set (&cpu_buffer->commit_page->page->commit,rb_page_write (cpu_buffer->commit_page)); RB_WARN_ON(cpu_buffer,
@@ -4632,7 +4638,12 @@ rb_get_reader_page(struct ring_buffer_pe/* * Make sure we see any padding after the write update -* (see rb_reset_tail()) +* (see rb_reset_tail()). +* +* In addition, a writer may be writing on the reader page +* if the page has not been fully filled, so the read barrier +* is also needed to make sure we see the content of what is +* committed by the writer (see rb_set_commit_to_write()). */ smp_rmb ();
Greg Kroah-Hartman
maintainerPATCH 91/93 mm/swap: fix swap_info_struct race between swapoff and get_swap_pages()
In reply to Greg Kroah-HartmanFrom: Rongwei Wang <[email protected]>
commit 6fe7d6b992113719e96744d974212df3fcddc76c upstream.
The si->lock must be held when deleting the si from the available list. Otherwise, another thread can re-add the si to the available list, which can lead to memory corruption. The only place we have found where this happens is in the swapoff path. This case can be described as below:
core 0 core 1
swapoff
del_from_avail_list(si) waiting
try lock si->lock acquire swap_avail_lock
and re-add si into
swap_avail_head
acquire si->lock but missing si already being added again, and continuing to clear SWP_WRITEOK, etc.
It can be easily found that a massive warning messages can be triggered inside get_swap_pages() by some special cases, for example, we call madvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile, run much swapon-swapoff operations (e.g. stress-ng-swap).
However, in the worst case, panic can be caused by the above scene. In swapoff(), the memory used by si could be kept in swap_info[] after turning off a swap. This means memory corruption will not be caused immediately until allocated and reset for a new swap in the swapon path. A panic message caused: (with CONFIG_PLIST_DEBUG enabled)
------------[ cut here ]------------ top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451a prev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8d next: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451a WARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70 Modules linked in: rfkill(E) crct10dif_ce(E)... CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+ Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) pc : plist_check_prev_next_node+0x50/0x70 lr : plist_check_prev_next_node+0x50/0x70
sp : ffff0018009d3c30
x29: ffff0018009d3c40 x28: ffff800011b32a98
x27: 0000000000000000 x26: ffff001803908000
x25: ffff8000128ea088 x24: ffff800011b32a48
x23: 0000000000000028 x22: ffff001800875c00
x21: ffff800010f9e520 x20: ffff001800875c00
x19: ffff001800fdc6e0 x18: 0000000000000030
x17: 0000000000000000 x16: 0000000000000000
x15: 0736076307640766 x14: 0730073007380731
x13: 0736076307640766 x12: 0730073007380731
x11: 000000000004058d x10: 0000000085a85b76
x9 : ffff8000101436e4 x8 : ffff800011c8ce08
x7 : 0000000000000000 x6 : 0000000000000001
x5 : ffff0017df9ed338 x4 : 0000000000000001
x3 : ffff8017ce62a000 x2 : ffff0017df9ed340
x1 : 0000000000000000 x0 : 0000000000000000
Call trace: plist_check_prev_next_node+0x50/0x70 plist_check_head+0x80/0xf0 plist_add+0x28/0x140 add_to_avail_list+0x9c/0xf0 _enable_swap_info+0x78/0xb4 __do_sys_swapon+0x918/0xa10 __arm64_sys_swapon+0x20/0x30 el0_svc_common+0x8c/0x220 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180 irq event stamp: 2082270
Now, si->lock locked before calling 'del_from_avail_list()' to make sure other thread see the si had been deleted and SWP_WRITEOK cleared together, will not reinsert again.
This problem exists in versions after stable 5.10.y.
--- mm/swapfile.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
mm/swapfile.c +2 -1
@@ -673,6 +673,7 @@ static void __del_from_avail_list(struct {int nid; +assert_spin_locked (&p->lock);for_each_node (nid)plist_del (&p->avail_lists[nid], &swap_avail_heads[nid]); }
@@ -2565,8 +2566,8 @@ SYSCALL_DEFINE1(swapoff, const char __usspin_unlock (&swap_lock); goto out_dput; } -del_from_avail_list (p);spin_lock (&p->lock); +del_from_avail_list (p);if (p->prio <0 ) {struct swap_info_struct *si = p;int nid;
Greg Kroah-Hartman
maintainerPATCH 92/93 drm/bridge: lt9611: Fix PLL being unable to lock
In reply to Greg Kroah-HartmanFrom: Robert Foss <[email protected]>
commit 2a9df204be0bbb896e087f00b9ee3fc559d5a608 upstream.
This fixes PLL being unable to lock, and is derived from an equivalent downstream commit.
Available LT9611 documentation does not list this register, neither does LT9611UXC (which is a different chip).
This commit has been confirmed to fix HDMI output on DragonBoard 845c.
--- drivers/gpu/drm/bridge/lontium-lt9611.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/bridge/lontium-lt9611.c +1 -0
@@ -256,6 +256,7 @@ static int lt9611_pll_setup(struct lt961 { 0x8126, 0x55 }, { 0x8127, 0x66 }, { 0x8128, 0x88 }, + { 0x812a, 0x20 }, };regmap_multi_reg_write (lt9611->regmap, reg_cfg,ARRAY_SIZE (reg_cfg));
Greg Kroah-Hartman
maintainerPATCH 93/93 mm: take a page reference when removing device exclusive entries
In reply to Greg Kroah-HartmanFrom: Alistair Popple <[email protected]>
commit 7c7b962938ddda6a9cd095de557ee5250706ea88 upstream.
Device exclusive page table entries are used to prevent CPU access to a page whilst it is being accessed from a device. Typically this is used to implement atomic operations when the underlying bus does not support atomic access. When a CPU thread encounters a device exclusive entry it locks the page and restores the original entry after calling mmu notifiers to signal drivers that exclusive access is no longer available.
The device exclusive entry holds a reference to the page making it safe to access the struct page whilst the entry is present. However the fault handling code does not hold the PTL when taking the page lock. This means if there are multiple threads faulting concurrently on the device exclusive entry one will remove the entry whilst others will wait on the page lock without holding a reference.
This can lead to threads locking or waiting on a folio with a zero refcount. Whilst mmap_lock prevents the pages getting freed via munmap() they may still be freed by a migration. This leads to warnings such as PAGE_FLAGS_CHECK_AT_FREE due to the page being locked when the refcount drops to zero.
Fix this by trying to take a reference on the folio before locking it. The code already checks the PTE under the PTL and aborts if the entry is no longer there. It is also possible the folio has been unmapped, freed and re-allocated allowing a reference to be taken on an unrelated folio. This case is also detected by the PTE check and the folio is unlocked without further changes.
--- mm/memory.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
mm/memory.c +15 -1
@@ -3462,8 +3462,21 @@ static vm_fault_t remove_device_exclusivstruct vm_area_struct *vma = vmf->vma;struct mmu_notifier_range range; -if (!lock_page_or_retry (page, vma->vm_mm, vmf->flags)) +/* +* We need a reference to lock the page because we don't hold +* the PTL so a racing thread can remove the device-exclusive +* entry and unmap it. If the page is free the entry must +* have been removed already. If it happens to have already +* been re-allocated after being freed all we do is lock and +* unlock it. +*/ +if (!get_page_unless_zero (page)) +return 0 ; + +if (!lock_page_or_retry (page, vma->vm_mm, vmf->flags)) { +put_page (page);return VM_FAULT_RETRY ; + }mmu_notifier_range_init_owner (&range,MMU_NOTIFY_EXCLUSIVE ,0 , vma, vma->vm_mm, vmf->address &PAGE_MASK , (vmf->address &PAGE_MASK ) +PAGE_SIZE ,NULL );
@@ -3476,6 +3489,7 @@ static vm_fault_t remove_device_exclusivpte_unmap_unlock (vmf->pte, vmf->ptl);unlock_page (page); +put_page (page);mmu_notifier_invalidate_range_end (&range);return 0 ;
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.107 release. There are 93 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 14 Apr 2023 08:28:02 +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.107-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.107 release. There are 93 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 14 Apr 2023 08:28:02 +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.107-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
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.107 release. There are 93 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 14 Apr 2023 08:28:02 +0000. Anything received after that time might be too late.
Build results:
total: 160 pass: 160 fail: 0 Qemu test results: total: 499 pass: 499 fail: 0
Guenter
Re: [PATCH 5.15 00/93] 5.15.107-rc1 review (possible amdgpu regression)
In reply to Greg Kroah-HartmanQuoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.107 release. There are 93 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 14 Apr 2023 08:28:02 +0000. Anything received after that time might be too late.
I think I'm seeing a regression here in the amdgpu driver, though not being a kernel dev I could be wrong.
I built and booted this today on an x86_64 machine (AMD Ryzen 7 3700X, Gigabyte X570 UD motherboard) with 3 x AMD graphics cards (using names from lspci output):
- Cape Verde GL [FirePro W4100]
- Oland XT [Radeon HD 8670 / R5 340X OEM / R7 250/350/350X OEM] (rev 83)
- Bonaire [Radeon R7 200 Series]
All three using the amdgpu driver (radeon module blacklisted).
This machine has been running vanilla 5.15 stable releases for a good while, with the kernel updated with whatever the latest 5.15 release is every 6 weeks or so. Never had any amdgpu problems.
To build 5.15.107-rc1 I applied the contents of the queue-5.15 directory on top of 5.15.106, having synced the stable queue git repo up until commit 344d8ad1b5dde387d1ce4d1be2641753b89dd10d (still the latest commit as a type). This is what I have done for years running vanilla stable kernels.
There was nothing out of the ordinary in the build output, but on rebooting into 5.15.107-rc1 I had the following error in dmesg from 1 card only:
amdgpu 0000:0d:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on vce0 (-110). [drm:process_one_work] *ERROR* ib ring test failed (-110).
This was during bootup immediately after driver loading. X is not running. 0000:0d:00.0 is the Bonaire card.
I then shutdown and fully powered off for a few minutes, booted 5.15.107-rc1 again, but the error on that card persisted exactly the same.
This was a regression for me as I've never had that error before on any kernel release (I grepped through old kernel logs to check).
I then rebuilt 5.15.107-rc1 but without applying the following 4 patches:
drm-panfrost-fix-the-panfrost_mmu_map_fault_addr-error-path.patch drm-amdgpu-fix-amdgpu_job_free_resources-v2.patch drm-amdgpu-prevent-race-between-late-signaled-fences.patch drm-bridge-lt9611-fix-pll-being-unable-to-lock.patch
On booting into the newly built kernel there was no error anymore, amdgpu dmesg output was as normal, and the machine is running fine now on that.
So I'm quite confident one of those patches introduced the error for me. Having now looked at the contents of them I see the lt9611 is entirely different hardware and I'm guessing the panfrost one probably is as well, so most likely I didn't need to remove those 2.
This is not a great report and maybe not helpful (sorry) as unfortunately I cannot try and narrow it down further to a single patch as this machine has to stay running now for a while. I just crudely tried yanking those 4 to hopefully get rid of the error and get the machine running again. Also I didn't go on to test whether the card actually worked as expected, maybe the error is harmless after all, though it doesn't look insignificant.
As the error was only output for the Bonaire card (the other two were fine), below is lspci -vvv output for that card only in case it helps. If anyone would like further info just let me know.
Eddie
0d:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire [Radeon R7 200 Series] (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] Bonaire
[Radeon R7 200 Series]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 135
IOMMU group: 29
Region 0: Memory at 880000000 (64-bit, prefetchable) [size=1G]
Region 2: Memory at 860000000 (64-bit, prefetchable) [size=8M]
Region 4: I/O ports at f000 [size=256]
Region 5: Memory at fce00000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at fce40000 [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 <?>
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mAPME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+
AuxPwr- TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1,
Exit Latency L0s <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x16
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-
NROPrPrP- LTR-
10BitTagComp- 10BitTagReq- OBFF Not Supported,
ExtFmt+ EETLPPrefix+, MaxEETLPPrefixes 1
EmergencyPowerReduction Not Supported,
EmergencyPowerReductionInit-
FRS-
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LTR- 10BitTagReq- OBFF Disabled,
AtomicOpsCtl: ReqEn-
LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink-
Retimer- 2Retimers- DRS-
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance-
SpeedDis-
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance Preset/De-emphasis: -6dB
de-emphasis, 0dB preshoot
LnkSta2: Current De-emphasis Level: -3.5dB,
EqualizationComplete+ EqualizationPhase1+
EqualizationPhase2+ EqualizationPhase3+
LinkEqualizationRequest-
Retimer- 2Retimers- CrosslinkRes: unsupported
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee00000 Data: 0000
Capabilities: [100 v1] Vendor Specific Information: ID=0001
Rev=1 Len=010 <?>
Capabilities: [150 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
AdvNonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
AdvNonFatalErr+
AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn-
ECRCChkCap+ ECRCChkEn-
MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
HeaderLog: 00000000 00000000 00000000 00000000
Capabilities: [200 v1] Physical Resizable BAR
BAR 0: current size: 1GB, supported: 256MB 512MB 1GB
Capabilities: [270 v1] Secondary PCI Express
LnkCtl3: LnkEquIntrruptEn- PerformEqu-
LaneErrStat: 0
Capabilities: [2b0 v1] Address Translation Service (ATS)
ATSCap: Invalidate Queue Depth: 00
ATSCtl: Enable+, Smallest Translation Unit: 00
Capabilities: [2c0 v1] Page Request Interface (PRI)
PRICtl: Enable- Reset-
PRISta: RF- UPRGI- Stopped+
Page Request Capacity: 00000020, Page Request
Allocation: 00000000
Capabilities: [2d0 v1] Process Address Space ID (PASID)
PASIDCap: Exec+ Priv+, Max PASID Width: 10
PASIDCtl: Enable- Exec- Priv-
Kernel driver in use: amdgpu
Kernel modules: radeon, amdgpu
Greg Kroah-Hartman
maintainerRe: [PATCH 5.15 00/93] 5.15.107-rc1 review (possible amdgpu regression)
Quoted 69 lines · Eddie Chapman
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.107 release. There are 93 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 14 Apr 2023 08:28:02 +0000. Anything received after that time might be too late.
I think I'm seeing a regression here in the amdgpu driver, though not being a kernel dev I could be wrong.
I built and booted this today on an
x86_64machine (AMD Ryzen 7 3700X, Gigabyte X570 UD motherboard) with 3 x AMD graphics cards (using names from lspci output):
- Cape Verde GL [FirePro W4100]
- Oland XT [Radeon HD 8670 / R5 340X OEM / R7 250/350/350X OEM] (rev 83)
- Bonaire [Radeon R7 200 Series]All three using the amdgpu driver (radeon module blacklisted).
This machine has been running vanilla 5.15 stable releases for a good while, with the kernel updated with whatever the latest 5.15 release is every 6 weeks or so. Never had any amdgpu problems.
To build 5.15.107-rc1 I applied the contents of the queue-5.15 directory on top of 5.15.106, having synced the stable queue git repo up until commit
344d8ad1b5dde387d1ce4d1be2641753b89dd10d(still the latest commit as a type). This is what I have done for years running vanilla stable kernels.There was nothing out of the ordinary in the build output, but on rebooting into 5.15.107-rc1 I had the following error in dmesg from 1 card only:
amdgpu 0000:0d:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on vce0 (-110).
[drm:process_one_work] *ERROR* ib ring test failed (-110).This was during bootup immediately after driver loading. X is not running. 0000:0d:00.0 is the Bonaire card.
I then shutdown and fully powered off for a few minutes, booted 5.15.107-rc1 again, but the error on that card persisted exactly the same.
This was a regression for me as I've never had that error before on any kernel release (I grepped through old kernel logs to check).
I then rebuilt 5.15.107-rc1 but without applying the following 4 patches:
drm-panfrost-fix-the-panfrost_mmu_map_fault_addr-error-path.patch drm-amdgpu-fix-amdgpu_job_free_resources-v2.patch drm-amdgpu-prevent-race-between-late-signaled-fences.patch drm-bridge-lt9611-fix-pll-being-unable-to-lock.patch
On booting into the newly built kernel there was no error anymore, amdgpu dmesg output was as normal, and the machine is running fine now on that.
So I'm quite confident one of those patches introduced the error for me. Having now looked at the contents of them I see the lt9611 is entirely different hardware and I'm guessing the panfrost one probably is as well, so most likely I didn't need to remove those 2.
This is not a great report and maybe not helpful (sorry) as unfortunately I cannot try and narrow it down further to a single patch as this machine has to stay running now for a while. I just crudely tried yanking those 4 to hopefully get rid of the error and get the machine running again. Also I didn't go on to test whether the card actually worked as expected, maybe the error is harmless after all, though it doesn't look insignificant.
Quoted 3 lines
As the error was only output for the Bonaire card (the other two were fine), below is lspci -vvv output for that card only in case it helps. If anyone would like further info just let me know.
Ok, I've dropped the two drm-amdgpu-* patches from the tree for now. Let me know if the release works properly for you or not.
thanks for testing and letting us know!
greg k-h
Re: [PATCH 5.15 00/93] 5.15.107-rc1 review (possible amdgpu regression)
Quoted 74 lines · Greg Kroah-Hartman
Quoted 69 lines · Eddie Chapman
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.107 release. There are 93 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 14 Apr 2023 08:28:02 +0000. Anything received after that time might be too late.
I think I'm seeing a regression here in the amdgpu driver, though not being a kernel dev I could be wrong.
I built and booted this today on an
x86_64machine (AMD Ryzen 7 3700X, Gigabyte X570 UD motherboard) with 3 x AMD graphics cards (using names from lspci output):
- Cape Verde GL [FirePro W4100]
- Oland XT [Radeon HD 8670 / R5 340X OEM / R7 250/350/350X OEM] (rev 83)
- Bonaire [Radeon R7 200 Series]All three using the amdgpu driver (radeon module blacklisted).
This machine has been running vanilla 5.15 stable releases for a good while, with the kernel updated with whatever the latest 5.15 release is every 6 weeks or so. Never had any amdgpu problems.
To build 5.15.107-rc1 I applied the contents of the queue-5.15 directory on top of 5.15.106, having synced the stable queue git repo up until commit
344d8ad1b5dde387d1ce4d1be2641753b89dd10d(still the latest commit as a type). This is what I have done for years running vanilla stable kernels.There was nothing out of the ordinary in the build output, but on rebooting into 5.15.107-rc1 I had the following error in dmesg from 1 card only:
amdgpu 0000:0d:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on vce0 (-110).
[drm:process_one_work] *ERROR* ib ring test failed (-110).This was during bootup immediately after driver loading. X is not running. 0000:0d:00.0 is the Bonaire card.
I then shutdown and fully powered off for a few minutes, booted 5.15.107-rc1 again, but the error on that card persisted exactly the same.
This was a regression for me as I've never had that error before on any kernel release (I grepped through old kernel logs to check).
I then rebuilt 5.15.107-rc1 but without applying the following 4 patches:
drm-panfrost-fix-the-panfrost_mmu_map_fault_addr-error-path.patch drm-amdgpu-fix-amdgpu_job_free_resources-v2.patch drm-amdgpu-prevent-race-between-late-signaled-fences.patch drm-bridge-lt9611-fix-pll-being-unable-to-lock.patch
On booting into the newly built kernel there was no error anymore, amdgpu dmesg output was as normal, and the machine is running fine now on that.
So I'm quite confident one of those patches introduced the error for me. Having now looked at the contents of them I see the lt9611 is entirely different hardware and I'm guessing the panfrost one probably is as well, so most likely I didn't need to remove those 2.
This is not a great report and maybe not helpful (sorry) as unfortunately I cannot try and narrow it down further to a single patch as this machine has to stay running now for a while. I just crudely tried yanking those 4 to hopefully get rid of the error and get the machine running again. Also I didn't go on to test whether the card actually worked as expected, maybe the error is harmless after all, though it doesn't look insignificant.
Quoted 3 lines
As the error was only output for the Bonaire card (the other two were fine), below is lspci -vvv output for that card only in case it helps. If anyone would like further info just let me know.
Quoted 6 lines
Ok, I've dropped the two drm-amdgpu-* patches from the tree for now. Let me know if the release works properly for you or not.
thanks for testing and letting us know!
greg k-h
Hello Greg,
My apologies just realised I never got back to you, as requested, to confirm that, yes, that final release of 5.15.107 as well as other 5.15.x releases I've tried since then (including 5.15.115) have booted up fine, without any unexpected errors, with these 3 AMD cards all using the amdgpu driver, each with monitors connected.
Eddie
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.107 release. There are 93 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 10.2.0) and powerpc (ps3_defconfig, GCC 12.2.0).
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.107 release. There are 93 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 14 Apr 2023 08:28:02 +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.107-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).
Note: This was built with a .config change from CONFIG_SIFIVE_L2 to CONFIG_SIFIVE_CCACHE.
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.107 release. There are 93 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 14 Apr 2023 08:28:02 +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.107-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.107-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: 415a9d81c640534731472ca364ec9cb77008a8e0
* git describe: v5.15.105-194-g415a9d81c640
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.105-194-g415a9d81c640
## Test Regressions (compared to v5.15.105)
## Metric Regressions (compared to v5.15.105)
## Test Fixes (compared to v5.15.105)
## Metric Fixes (compared to v5.15.105)
## Test result summary
total: 126997, pass: 105591, fail: 3746, skip: 17417, xfail: 243
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 115 total, 114 passed, 1 failed
* arm64: 43 total, 41 passed, 2 failed
* i386: 33 total, 30 passed, 3 failed
* mips: 27 total, 26 passed, 1 failed
* parisc: 8 total, 8 passed, 0 failed
* powerpc: 27 total, 26 passed, 1 failed
* riscv: 11 total, 11 passed, 0 failed
* s390: 12 total, 11 passed, 1 failed
* sh: 14 total, 12 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 36 total, 34 passed, 2 failed
## Test suites summary
* boot
* fwts
* igt-gpu-tools
* 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-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* 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-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libhugetlbfs
* 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-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Hi Greg,
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.107 release. There are 93 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.
No problems seen on x86_64 and aarch64.
Thanks,
Harshit