This is the start of the stable review cycle for the 5.19.13 release.
There are 101 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 Wed, 05 Oct 2022 07:07:06 +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.19.13-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.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.19.13-rc1
Levi Yun <[email protected]>
damon/sysfs: fix possible memleak on damon_sysfs_add_target
Nadav Amit <[email protected]>
x86/alternative: Fix race in try_get_desc()
Borislav Petkov <[email protected]>
x86/cacheinfo: Add a cpu_llc_shared_mask() UP variant
Jim Mattson <[email protected]>
KVM: x86: Hide IA32_PLATFORM_DCA_CAP[31:0] from the guest
Arnaldo Carvalho de Melo <[email protected]>
perf tests record: Fail the test if the 'errs' counter is not zero
Zhengjun Xing <[email protected]>
perf test: Fix test case 87 ("perf record tests") for hybrid systems
Daniel Golle <[email protected]>
net: ethernet: mtk_eth_soc: fix mask of RX_DMA_GET_SPORT{,_V2}
Vladimir Oltean <[email protected]>
net: mscc: ocelot: fix tagged VLAN refusal while under a VLAN-unaware bridge
Peng Fan <[email protected]>
clk: imx93: drop of_match_ptr
Florian Fainelli <[email protected]>
clk: iproc: Do not rely on node name for correct PLL setup
Ashutosh Dixit <[email protected]>
drm/i915/gt: Perf_limit_reasons are only available for Gen11+
Han Xu <[email protected]>
clk: imx: imx6sx: remove the SET_RATE_PARENT flag for QSPI clocks
Al Viro <[email protected]>
don't use __kernel_write() on kmap_local_page()
Eli Cohen <[email protected]>
vdpa/mlx5: Fix MQ to support non power of two num queues
Suwan Kim <[email protected]>
virtio-blk: Fix WARN_ON_ONCE in virtio_queue_rq()
Angus Chen <[email protected]>
vdpa/ifcvf: fix the calculation of queuepair
Maciej Fijalkowski <[email protected]>
ice: xsk: drop power of 2 ring size restriction for AF_XDP
Maciej Fijalkowski <[email protected]>
ice: xsk: change batched Tx descriptor cleaning
Wang Yufen <[email protected]>
selftests: Fix the if conditions of in test_extra_filter()
Lukas Wunner <[email protected]>
net: phy: Don't WARN for PHY_UP state in mdio_bus_phy_resume()
Junxiao Chang <[email protected]>
net: stmmac: power up/down serdes in stmmac_open/release
Paweł Lenkow <[email protected]>
wifi: mac80211: fix memory corruption in minstrel_ht_update_rates()
Hans de Goede <[email protected]>
wifi: mac80211: fix regression with non-QoS drivers
Tamizh Chelvam Raja <[email protected]>
wifi: cfg80211: fix MCS divisor value
Michael Kelley <[email protected]>
nvme: Fix IOC_PR_CLEAR and IOC_PR_RELEASE ioctls for nvme devices
Peng Wu <[email protected]>
net/mlxbf_gige: Fix an IS_ERR() vs NULL bug in mlxbf_gige_mdio_probe
Rafael Mendonca <[email protected]>
cxgb4: fix missing unlock on ETHOFLD desc collect fail path
Hangyu Hua <[email protected]>
net: sched: act_ct: fix possible refcount leak in tcf_ct_init()
Peilin Ye <[email protected]>
usbnet: Fix memory leak in usbnet_disconnect()
Zhengjun Xing <[email protected]>
perf parse-events: Remove "not supported" hybrid cache events
Zhengjun Xing <[email protected]>
perf print-events: Fix "perf list" can not display the PMU prefix for some hybrid cache events
Ian Rogers <[email protected]>
perf parse-events: Break out tracepoint and printing
Pali Rohár <[email protected]>
gpio: mvebu: Fix check for pwm support on non-A8K platforms
Yang Yingliang <[email protected]>
Input: melfas_mip4 - fix return value check in mip4_probe()
Brian Norris <[email protected]>
Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time"
Radhey Shyam Pandey <[email protected]>
net: macb: Fix ZynqMP SGMII non-wakeup source resume failure
Francesco Dolcini <[email protected]>
drm/bridge: lt8912b: fix corrupted image output
Philippe Schenker <[email protected]>
drm/bridge: lt8912b: set hdmi or dvi mode
Philippe Schenker <[email protected]>
drm/bridge: lt8912b: add vsync hsync
Martin Povišer <[email protected]>
ASoC: tas2770: Reinit regcache on reset
Johan Hovold <[email protected]>
arm64: dts: qcom: sm8350: fix UFS PHY serdes size
Conor Dooley <[email protected]>
clk: microchip: mpfs: make the rtc's ahb clock critical
Conor Dooley <[email protected]>
clk: microchip: mpfs: fix clk_cfg array bounds violation
Shengjiu Wang <[email protected]>
ASoC: imx-card: Fix refcount issue with of_node_put
Samuel Holland <[email protected]>
soc: sunxi: sram: Fix debugfs info for A64 SRAM C
Samuel Holland <[email protected]>
soc: sunxi: sram: Fix probe function ordering issues
Samuel Holland <[email protected]>
soc: sunxi: sram: Prevent the driver from being unbound
Samuel Holland <[email protected]>
soc: sunxi: sram: Actually claim SRAM regions
Romain Naour <[email protected]>
ARM: dts: am5748: keep usb4_tm disabled
Richard Zhu <[email protected]>
reset: imx7: Fix the iMX8MP PCIe PHY PERST support
YuTong Chang <[email protected]>
ARM: dts: am33xx: Fix MMCHS0 dma properties
Hans Verkuil <[email protected]>
media: v4l2-compat-ioctl32.c: zero buffer passed to v4l2_compat_get_array_args()
Nícolas F. R. A. Prado <[email protected]>
media: mediatek: vcodec: Drop platform_get_resource(IORESOURCE_IRQ)
Nicolas Dufresne <[email protected]>
media: rkvdec: Disable H.264 error detection
Hangyu Hua <[email protected]>
media: dvb_vb2: fix possible out of bound access
Shuai Xue <[email protected]>
mm,hwpoison: check mm when killing accessing process
Doug Berger <[email protected]>
mm/hugetlb: correct demote page offset logic
Sergei Antonov <[email protected]>
mm: bring back update_mmu_cache() to finish_fault()
Minchan Kim <[email protected]>
mm: fix madivse_pageout mishandling on non-LRU page
Alistair Popple <[email protected]>
mm/migrate_device.c: copy pte dirty bit to page
Alistair Popple <[email protected]>
mm/migrate_device.c: add missing flush_cache_page()
Alistair Popple <[email protected]>
mm/migrate_device.c: flush TLB while holding PTL
Binyi Han <[email protected]>
mm: fix dereferencing possible ERR_PTR
Zi Yan <[email protected]>
mm/page_isolation: fix isolate_single_pageblock() isolation behavior
Maurizio Lombardi <[email protected]>
mm: prevent page_frag_alloc() from corrupting the memory
Mel Gorman <[email protected]>
mm/page_alloc: fix race condition between build_all_zonelists and page allocation
Yang Shi <[email protected]>
mm: gup: fix the fast GUP race against THP collapse
Wenchao Chen <[email protected]>
mmc: hsq: Fix data stomping during mmc recovery
Sergei Antonov <[email protected]>
mmc: moxart: fix 4-bit bus width and remove 8-bit bus width
Menglong Dong <[email protected]>
mptcp: fix unreleased socket in accept queue
Menglong Dong <[email protected]>
mptcp: factor out __mptcp_close() without socket lock
Florian Westphal <[email protected]>
mm: fix BUG splat with kvmalloc + GFP_ATOMIC
Niklas Cassel <[email protected]>
libata: add ATA_HORKAGE_NOLPM for Pioneer BDR-207M and BDR-205
Maxime Coquelin <[email protected]>
vduse: prevent uninitialized memory accesses
Bokun Zhang <[email protected]>
drm/amdgpu: Add amdgpu suspend-resume code path under SRIOV
Chris Wilson <[email protected]>
drm/i915/gt: Restrict forced preemption to the active context
Yang Shi <[email protected]>
powerpc/64s/radix: don't need to broadcast IPI for radix pmd collapse flush
Ulf Hansson <[email protected]>
Revert "firmware: arm_scmi: Add clock management to the SCMI power domain"
Alexander Couzens <[email protected]>
net: mt7531: only do PLL once after the reset
Greg Kroah-Hartman <[email protected]>
mm/damon/dbgfs: fix memory leak when using debugfs_lookup()
Kees Cook <[email protected]>
x86/uaccess: avoid check_object_size() in copy_from_user_nmi()
ChenXiaoSong <[email protected]>
ntfs: fix BUG_ON in ntfs_lookup_inode_by_name()
Linus Walleij <[email protected]>
ARM: dts: integrator: Tag PCI host with device_type
Christoph Hellwig <[email protected]>
frontswap: don't call ->init if no ops are registered
Jarkko Sakkinen <[email protected]>
x86/sgx: Do not fail on incomplete sanitization on premature stop of ksgxd
Alexander Wetzel <[email protected]>
wifi: mac80211: ensure vif queues are operational after start
Aidan MacDonald <[email protected]>
clk: ingenic-tcu: Properly enable registers before accessing timers
Marc Kleine-Budde <[email protected]>
can: c_can: don't cache TX messages for C_CAN cores
Sebastian Krzyszkowiak <[email protected]>
Input: snvs_pwrkey - fix SNVS_HPVIDR1 register address
Frank Wunderlich <[email protected]>
net: usb: qmi_wwan: Add new usb-id for Dell branded EM7455
Mario Limonciello <[email protected]>
thunderbolt: Explicitly reset plug events delay back to USB4 spec value
Heikki Krogerus <[email protected]>
usb: typec: ucsi: Remove incorrect warning
Hongling Zeng <[email protected]>
uas: ignore UAS for Thinkplus chips
Hongling Zeng <[email protected]>
usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS
Hongling Zeng <[email protected]>
uas: add no-uas quirk for Hiksemi usb_disk
William Breathitt Gray <[email protected]>
counter: 104-quad-8: Fix skipped IRQ lines during events configuration
William Breathitt Gray <[email protected]>
counter: 104-quad-8: Implement and utilize register structures
William Breathitt Gray <[email protected]>
counter: 104-quad-8: Utilize iomap interface
Adrian Hunter <[email protected]>
perf record: Fix cpu mask bit setting for mixed mmaps
Athira Rajeev <[email protected]>
tools/perf: Fix out of bound access to cpu mask array
Heiko Stuebner <[email protected]>
riscv: make t-head erratas depend on MMU
-------------
Diffstat:
Makefile | 4 +-
arch/arm/boot/dts/am33xx-l4.dtsi | 3 +-
arch/arm/boot/dts/am5748.dtsi | 4 +
arch/arm/boot/dts/integratorap.dts | 1 +
arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
arch/powerpc/mm/book3s64/radix_pgtable.c | 9 -
arch/riscv/Kconfig.erratas | 2 +-
arch/x86/include/asm/smp.h | 25 +-
arch/x86/kernel/alternative.c | 45 +-
arch/x86/kernel/cpu/sgx/main.c | 15 +-
arch/x86/kvm/cpuid.c | 2 -
arch/x86/lib/usercopy.c | 2 +-
drivers/ata/libata-core.c | 4 +
drivers/block/virtio_blk.c | 11 +-
drivers/clk/bcm/clk-iproc-pll.c | 12 +-
drivers/clk/imx/clk-imx6sx.c | 4 +-
drivers/clk/imx/clk-imx93.c | 2 +-
drivers/clk/ingenic/tcu.c | 15 +-
drivers/clk/microchip/clk-mpfs.c | 11 +-
drivers/counter/104-quad-8.c | 209 +++---
drivers/firmware/arm_scmi/scmi_pm_domain.c | 26 -
drivers/gpio/gpio-mvebu.c | 15 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 4 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 27 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 -
drivers/gpu/drm/bridge/lontium-lt8912b.c | 13 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 15 +
.../gpu/drm/i915/gt/intel_execlists_submission.c | 21 +-
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 15 +-
drivers/input/keyboard/snvs_pwrkey.c | 2 +-
drivers/input/touchscreen/melfas_mip4.c | 2 +-
drivers/media/dvb-core/dvb_vb2.c | 11 +
.../platform/mediatek/vcodec/mtk_vcodec_enc_drv.c | 9 +-
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 2 +
drivers/mmc/host/mmc_hsq.c | 2 +-
drivers/mmc/host/moxart-mmc.c | 17 +-
drivers/net/can/c_can/c_can.h | 17 +-
drivers/net/can/c_can/c_can_main.c | 11 +-
drivers/net/dsa/mt7530.c | 15 +-
drivers/net/ethernet/cadence/macb_main.c | 4 +
drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 28 +-
drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +-
drivers/net/ethernet/intel/ice/ice_xsk.c | 163 ++---
drivers/net/ethernet/intel/ice/ice_xsk.h | 7 +-
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 4 +-
.../ethernet/mellanox/mlxbf_gige/mlxbf_gige_mdio.c | 4 +-
drivers/net/ethernet/mscc/ocelot.c | 7 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 23 +-
drivers/net/phy/phy_device.c | 10 +-
drivers/net/usb/qmi_wwan.c | 1 +
drivers/net/usb/usbnet.c | 7 +-
drivers/nvme/host/core.c | 6 +-
drivers/reset/reset-imx7.c | 1 +
drivers/soc/sunxi/sunxi_sram.c | 23 +-
drivers/staging/media/rkvdec/rkvdec-h264.c | 4 +-
drivers/thunderbolt/switch.c | 1 +
drivers/usb/storage/unusual_uas.h | 21 +
drivers/usb/typec/ucsi/ucsi.c | 2 -
drivers/vdpa/ifcvf/ifcvf_base.c | 4 +-
drivers/vdpa/mlx5/net/mlx5_vnet.c | 17 +-
drivers/vdpa/vdpa_user/vduse_dev.c | 9 +-
fs/coredump.c | 38 +-
fs/internal.h | 3 +
fs/ntfs/super.c | 3 +-
fs/read_write.c | 22 +-
mm/damon/dbgfs.c | 19 +-
mm/damon/sysfs.c | 2 +-
mm/frontswap.c | 3 +
mm/gup.c | 34 +-
mm/hugetlb.c | 14 +-
mm/khugepaged.c | 10 +-
mm/madvise.c | 7 +-
mm/memory-failure.c | 3 +
mm/memory.c | 14 +-
mm/migrate_device.c | 16 +-
mm/page_alloc.c | 65 +-
mm/page_isolation.c | 25 +-
mm/secretmem.c | 2 +-
mm/util.c | 4 +
net/mac80211/rc80211_minstrel_ht.c | 6 +-
net/mac80211/tx.c | 4 +
net/mac80211/util.c | 4 +-
net/mptcp/protocol.c | 16 +-
net/mptcp/protocol.h | 2 +
net/mptcp/subflow.c | 33 +-
net/sched/act_ct.c | 5 +-
net/wireless/util.c | 4 +-
sound/soc/codecs/tas2770.c | 3 +
sound/soc/fsl/imx-card.c | 4 +
tools/perf/builtin-list.c | 2 +-
tools/perf/builtin-lock.c | 1 +
tools/perf/builtin-record.c | 28 +-
tools/perf/builtin-timechart.c | 1 +
tools/perf/builtin-trace.c | 1 +
tools/perf/tests/perf-record.c | 2 +-
tools/perf/tests/shell/record.sh | 2 +-
tools/perf/util/Build | 2 +
tools/perf/util/parse-events-hybrid.c | 21 +-
tools/perf/util/parse-events.c | 734 ++-------------------
tools/perf/util/parse-events.h | 32 +-
tools/perf/util/print-events.c | 533 +++++++++++++++
tools/perf/util/print-events.h | 22 +
tools/perf/util/trace-event-info.c | 96 +++
tools/perf/util/tracepoint.c | 63 ++
tools/perf/util/tracepoint.h | 25 +
tools/testing/selftests/net/reuseport_bpf.c | 2 +-
106 files changed, 1628 insertions(+), 1271 deletions(-)
From: Han Xu <[email protected]>
[ Upstream commit b1ff1bfe81e763420afd5f3f25f0b3cbfd97055c ]
There is no dedicate parent clock for QSPI so SET_RATE_PARENT flag
should not be used. For instance, the default parent clock for QSPI is
pll2_bus, which is also the parent clock for quite a few modules, such
as MMDC, once GPMI NAND set clock rate for EDO5 mode can cause system
hang due to pll2_bus rate changed.
Fixes: f1541e15e38e ("clk: imx6sx: Switch to clk_hw based API")
Signed-off-by: Han Xu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Tested-by: Fabio Estevam <[email protected]>
Reviewed-by: Abel Vesa <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/clk/imx/clk-imx6sx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index fc1bd23d4583..598f3cf4eba4 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -280,13 +280,13 @@ static void __init imx6sx_clocks_init(struct device_node *ccm_node)
hws[IMX6SX_CLK_SSI3_SEL] = imx_clk_hw_mux("ssi3_sel", base + 0x1c, 14, 2, ssi_sels, ARRAY_SIZE(ssi_sels));
hws[IMX6SX_CLK_SSI2_SEL] = imx_clk_hw_mux("ssi2_sel", base + 0x1c, 12, 2, ssi_sels, ARRAY_SIZE(ssi_sels));
hws[IMX6SX_CLK_SSI1_SEL] = imx_clk_hw_mux("ssi1_sel", base + 0x1c, 10, 2, ssi_sels, ARRAY_SIZE(ssi_sels));
- hws[IMX6SX_CLK_QSPI1_SEL] = imx_clk_hw_mux_flags("qspi1_sel", base + 0x1c, 7, 3, qspi1_sels, ARRAY_SIZE(qspi1_sels), CLK_SET_RATE_PARENT);
+ hws[IMX6SX_CLK_QSPI1_SEL] = imx_clk_hw_mux("qspi1_sel", base + 0x1c, 7, 3, qspi1_sels, ARRAY_SIZE(qspi1_sels));
hws[IMX6SX_CLK_PERCLK_SEL] = imx_clk_hw_mux("perclk_sel", base + 0x1c, 6, 1, perclk_sels, ARRAY_SIZE(perclk_sels));
hws[IMX6SX_CLK_VID_SEL] = imx_clk_hw_mux("vid_sel", base + 0x20, 21, 3, vid_sels, ARRAY_SIZE(vid_sels));
hws[IMX6SX_CLK_ESAI_SEL] = imx_clk_hw_mux("esai_sel", base + 0x20, 19, 2, audio_sels, ARRAY_SIZE(audio_sels));
hws[IMX6SX_CLK_CAN_SEL] = imx_clk_hw_mux("can_sel", base + 0x20, 8, 2, can_sels, ARRAY_SIZE(can_sels));
hws[IMX6SX_CLK_UART_SEL] = imx_clk_hw_mux("uart_sel", base + 0x24, 6, 1, uart_sels, ARRAY_SIZE(uart_sels));
- hws[IMX6SX_CLK_QSPI2_SEL] = imx_clk_hw_mux_flags("qspi2_sel", base + 0x2c, 15, 3, qspi2_sels, ARRAY_SIZE(qspi2_sels), CLK_SET_RATE_PARENT);
+ hws[IMX6SX_CLK_QSPI2_SEL] = imx_clk_hw_mux("qspi2_sel", base + 0x2c, 15, 3, qspi2_sels, ARRAY_SIZE(qspi2_sels));
hws[IMX6SX_CLK_SPDIF_SEL] = imx_clk_hw_mux("spdif_sel", base + 0x30, 20, 2, audio_sels, ARRAY_SIZE(audio_sels));
hws[IMX6SX_CLK_AUDIO_SEL] = imx_clk_hw_mux("audio_sel", base + 0x30, 7, 2, audio_sels, ARRAY_SIZE(audio_sels));
hws[IMX6SX_CLK_ENET_PRE_SEL] = imx_clk_hw_mux("enet_pre_sel", base + 0x34, 15, 3, enet_pre_sels, ARRAY_SIZE(enet_pre_sels));
--
2.35.1
From: Junxiao Chang <[email protected]>
[ Upstream commit 49725ffc15fc4e9fae68c55b691fd25168cbe5c1 ]
This commit fixes DMA engine reset timeout issue in suspend/resume
with ADLink I-Pi SMARC Plus board which dmesg shows:
...
[ 54.678271] PM: suspend exit
[ 54.754066] intel-eth-pci 0000:00:1d.2 enp0s29f2: PHY [stmmac-3:01] driver [Maxlinear Ethernet GPY215B] (irq=POLL)
[ 54.755808] intel-eth-pci 0000:00:1d.2 enp0s29f2: Register MEM_TYPE_PAGE_POOL RxQ-0
...
[ 54.780482] intel-eth-pci 0000:00:1d.2 enp0s29f2: Register MEM_TYPE_PAGE_POOL RxQ-7
[ 55.784098] intel-eth-pci 0000:00:1d.2: Failed to reset the dma
[ 55.784111] intel-eth-pci 0000:00:1d.2 enp0s29f2: stmmac_hw_setup: DMA engine initialization failed
[ 55.784115] intel-eth-pci 0000:00:1d.2 enp0s29f2: stmmac_open: Hw setup failed
...
The issue is related with serdes which impacts clock. There is
serdes in ADLink I-Pi SMARC board ethernet controller. Please refer to
commit b9663b7ca6ff78 ("net: stmmac: Enable SERDES power up/down sequence")
for detial. When issue is reproduced, DMA engine clock is not ready
because serdes is not powered up.
To reproduce DMA engine reset timeout issue with hardware which has
serdes in GBE controller, install Ubuntu. In Ubuntu GUI, click
"Power Off/Log Out" -> "Suspend" menu, it disables network interface,
then goes to sleep mode. When it wakes up, it enables network
interface again. Stmmac driver is called in this way:
1. stmmac_release: Stop network interface. In this function, it
disables DMA engine and network interface;
2. stmmac_suspend: It is called in kernel suspend flow. But because
network interface has been disabled(netif_running(ndev) is
false), it does nothing and returns directly;
3. System goes into S3 or S0ix state. Some time later, system is
waken up by keyboard or mouse;
4. stmmac_resume: It does nothing because network interface has
been disabled;
5. stmmac_open: It is called to enable network interace again. DMA
engine is initialized in this API, but serdes is not power on so
there will be DMA engine reset timeout issue.
Similarly, serdes powerdown should be added in stmmac_release.
Network interface might be disabled by cmd "ifconfig eth0 down",
DMA engine, phy and mac have been disabled in ndo_stop callback,
serdes should be powered down as well. It doesn't make sense that
serdes is on while other components have been turned off.
If ethernet interface is in enabled state(netif_running(ndev) is true)
before suspend/resume, the issue couldn't be reproduced because serdes
could be powered up in stmmac_resume.
Because serdes_powerup is added in stmmac_open, it doesn't need to be
called in probe function.
Fixes: b9663b7ca6ff78 ("net: stmmac: Enable SERDES power up/down sequence")
Signed-off-by: Junxiao Chang <[email protected]>
Reviewed-by: Voon Weifeng <[email protected]>
Tested-by: Jimmy JS Chen <[email protected]>
Tested-by: Looi, Hong Aun <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 23 +++++++++++--------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 78f11dabca05..8d9272f01e31 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3704,6 +3704,15 @@ static int stmmac_open(struct net_device *dev)
goto init_error;
}
+ if (priv->plat->serdes_powerup) {
+ ret = priv->plat->serdes_powerup(dev, priv->plat->bsp_priv);
+ if (ret < 0) {
+ netdev_err(priv->dev, "%s: Serdes powerup failed\n",
+ __func__);
+ goto init_error;
+ }
+ }
+
ret = stmmac_hw_setup(dev, true);
if (ret < 0) {
netdev_err(priv->dev, "%s: Hw setup failed\n", __func__);
@@ -3793,6 +3802,10 @@ static int stmmac_release(struct net_device *dev)
/* Disable the MAC Rx/Tx */
stmmac_mac_set(priv, priv->ioaddr, false);
+ /* Powerdown Serdes if there is */
+ if (priv->plat->serdes_powerdown)
+ priv->plat->serdes_powerdown(dev, priv->plat->bsp_priv);
+
netif_carrier_off(dev);
stmmac_release_ptp(priv);
@@ -7158,14 +7171,6 @@ int stmmac_dvr_probe(struct device *device,
goto error_netdev_register;
}
- if (priv->plat->serdes_powerup) {
- ret = priv->plat->serdes_powerup(ndev,
- priv->plat->bsp_priv);
-
- if (ret < 0)
- goto error_serdes_powerup;
- }
-
#ifdef CONFIG_DEBUG_FS
stmmac_init_fs(ndev);
#endif
@@ -7180,8 +7185,6 @@ int stmmac_dvr_probe(struct device *device,
return ret;
-error_serdes_powerup:
- unregister_netdev(ndev);
error_netdev_register:
phylink_destroy(priv->phylink);
error_xpcs_setup:
--
2.35.1
From: Hangyu Hua <[email protected]>
[ Upstream commit 6e23ec0ba92d426c77a73a9ccab16346e5e0ef49 ]
nf_ct_put need to be called to put the refcount got by tcf_ct_fill_params
to avoid possible refcount leak when tcf_ct_flow_table_get fails.
Fixes: c34b961a2492 ("net/sched: act_ct: Create nf flow table per zone")
Signed-off-by: Hangyu Hua <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/sched/act_ct.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/sched/act_ct.c b/net/sched/act_ct.c
index e013253b10d1..4d44a1bf4a04 100644
--- a/net/sched/act_ct.c
+++ b/net/sched/act_ct.c
@@ -1393,7 +1393,7 @@ static int tcf_ct_init(struct net *net, struct nlattr *nla,
err = tcf_ct_flow_table_get(params);
if (err)
- goto cleanup;
+ goto cleanup_params;
spin_lock_bh(&c->tcf_lock);
goto_ch = tcf_action_set_ctrlact(*a, parm->action, goto_ch);
@@ -1408,6 +1408,9 @@ static int tcf_ct_init(struct net *net, struct nlattr *nla,
return res;
+cleanup_params:
+ if (params->tmpl)
+ nf_ct_put(params->tmpl);
cleanup:
if (goto_ch)
tcf_chain_put_by_act(goto_ch);
--
2.35.1
From: Lukas Wunner <[email protected]>
[ Upstream commit ea64cdfad124922c931633e39287c5a31a9b14a1 ]
Commit 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume()
state") introduced a WARN() on resume from system sleep if a PHY is not
in PHY_HALTED state.
Commit 6dbe852c379f ("net: phy: Don't WARN for PHY_READY state in
mdio_bus_phy_resume()") added an exemption for PHY_READY state from
the WARN().
It turns out PHY_UP state needs to be exempted as well because the
following may happen on suspend:
mdio_bus_phy_suspend()
phy_stop_machine()
phydev->state = PHY_UP # if (phydev->state >= PHY_UP)
Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
Reported-by: Marek Szyprowski <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Link: https://lore.kernel.org/netdev/[email protected]/
Signed-off-by: Lukas Wunner <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
Cc: Xiaolei Wang <[email protected]>
Link: https://lore.kernel.org/r/8128fdb51eeebc9efbf3776a4097363a1317aaf1.1663905575.git.lukas@wunner.de
Signed-off-by: Paolo Abeni <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/phy/phy_device.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index f90a21781d8d..adc9d97cbb88 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -316,11 +316,13 @@ static __maybe_unused int mdio_bus_phy_resume(struct device *dev)
phydev->suspended_by_mdio_bus = 0;
- /* If we manged to get here with the PHY state machine in a state neither
- * PHY_HALTED nor PHY_READY this is an indication that something went wrong
- * and we should most likely be using MAC managed PM and we are not.
+ /* If we managed to get here with the PHY state machine in a state
+ * neither PHY_HALTED, PHY_READY nor PHY_UP, this is an indication
+ * that something went wrong and we should most likely be using
+ * MAC managed PM, but we are not.
*/
- WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY);
+ WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY &&
+ phydev->state != PHY_UP);
ret = phy_init_hw(phydev);
if (ret < 0)
--
2.35.1
On Mon, Oct 03, 2022 at 09:09:56AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.19.13 release.
> There are 101 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 Wed, 05 Oct 2022 07:07:06 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 150 pass: 150 fail: 0
Qemu test results:
total: 490 pass: 490 fail: 0
Tested-by: Guenter Roeck <[email protected]>
Guenter
On 10/3/22 00:09, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.19.13 release.
> There are 101 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 Wed, 05 Oct 2022 07:07:06 +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.19.13-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <[email protected]>
--
Florian
On Mon, Oct 03, 2022 at 09:09:56AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.19.13 release.
> There are 101 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 Wed, 05 Oct 2022 07:07:06 +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.19.13-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le,
s390x, x86_64), and boot tested x86_64. No regressions noted.
Tested-by: Justin M. Forbes <[email protected]>
On 10/3/22 01:09, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.19.13 release.
> There are 101 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 Wed, 05 Oct 2022 07:07:06 +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.19.13-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
On Mon, Oct 3, 2022 at 8:56 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.19.13 release.
> There are 101 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 Wed, 05 Oct 2022 07:07:06 +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.19.13-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Hi Greg,
Compiled and booted on my test system Lenovo P50s: Intel Core i7
No emergency and critical messages in the dmesg
./perf bench sched all
# Running sched/messaging benchmark...
# 20 sender and receiver processes per group
# 10 groups == 400 processes run
Total time: 0.740 [sec]
# Running sched/pipe benchmark...
# Executed 1000000 pipe operations between two processes
Total time: 9.647 [sec]
9.647452 usecs/op
103654 ops/sec
Tested-by: Zan Aziz <[email protected]>
Thanks
-Zan
On 10/3/22 12:09 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.19.13 release.
> There are 101 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 Wed, 05 Oct 2022 07:07:06 +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.19.13-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Tested-by: Ron Economos <[email protected]>
On Mon, 3 Oct 2022 at 12:43, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.19.13 release.
> There are 101 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 Wed, 05 Oct 2022 07:07:06 +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.19.13-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.19.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.
Tested-by: Linux Kernel Functional Testing <[email protected]>
NOTE:
1) Build warning
2) Boot warning on qemu-arm64 with KASAN and Kunit test
Suspecting one of the recently commits causing this warning and
need to bisect to confirm the commit id.
mm/slab_common: fix possible double free of kmem_cache
[ Upstream commit d71608a877362becdc94191f190902fac1e64d35 ]
1) Following build warning found on few arm configs which do not set Kconfig
# CONFIG_ELF_CORE is not set
- powerpc: tqm8xx_defconfig
- arm: keystone_defconfig and omap1_defconfig
- mips: ar7_defconfig
fs/coredump.c:835:12: warning: 'dump_emit_page' defined but not used
[-Wunused-function]
835 | static int dump_emit_page(struct coredump_params *cprm, struct
page *page)
| ^~~~~~~~~~~~~~
2) Following kernel boot warning noticed on qemu-arm64 with KASAN and
KUNIT enabled [1]
[ 177.651182] ------------[ cut here ]------------
[ 177.652217] kmem_cache_destroy test: Slab cache still has
objects when called from test_exit+0x28/0x40
[ 177.654849] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:520
kmem_cache_destroy+0x1e8/0x20c
[ 177.666237] Modules linked in:
[ 177.667325] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B
5.19.13-rc1 #1
[ 177.668666] Hardware name: linux,dummy-virt (DT)
[ 177.669783] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT
-SSBS BTYPE=--)
[ 177.671120] pc : kmem_cache_destroy+0x1e8/0x20c
[ 177.672217] lr : kmem_cache_destroy+0x1e8/0x20c
[ 177.673302] sp : ffff8000080876f0
[ 177.674013] x29: ffff8000080876f0 x28: ffffb5ed1da56f38 x27:
ffffb5ed1a87b480
[ 177.676478] x26: ffff800008087aa0 x25: ffff800008087ac8 x24:
ffff00000c73b480
[ 177.678215] x23: 000000004c800000 x22: ffffb5ed1eca3000 x21:
ffffb5ed1da381f0
[ 177.679873] x20: fdecb5ed18ea3a78 x19: ffff00000759be00 x18:
00000000ffffffff
[ 177.681540] x17: 0000000000000000 x16: 0000000000000000 x15:
0000000000000000
[ 177.683139] x14: 0000000000000000 x13: 206d6f7266206465 x12:
ffff700001010e63
[ 177.684776] x11: 1ffff00001010e62 x10: ffff700001010e62 x9 :
ffffb5ed18b89514
[ 177.686554] x8 : ffff800008087317 x7 : 0000000000000001 x6 :
0000000000000001
[ 177.688238] x5 : ffffb5ed1d893000 x4 : dfff800000000000 x3 :
ffffb5ed18b89520
[ 177.689912] x2 : 0000000000000000 x1 : 0000000000000000 x0 :
ffff000007150000
[ 177.691598] Call trace:
[ 177.692165] kmem_cache_destroy+0x1e8/0x20c
[ 177.693196] test_exit+0x28/0x40
[ 177.694158] kunit_catch_run_case+0x5c/0x120
[ 177.695177] kunit_try_catch_run+0x144/0x26c
[ 177.696211] kunit_run_case_catch_errors+0x158/0x1e0
[ 177.697353] kunit_run_tests+0x374/0x750
[ 177.698333] __kunit_test_suites_init+0x74/0xa0
[ 177.699386] kunit_run_all_tests+0x160/0x380
[ 177.700428] kernel_init_freeable+0x32c/0x388
[ 177.701497] kernel_init+0x2c/0x150
[ 177.702347] ret_from_fork+0x10/0x20
[ 177.703308] ---[ end trace 0000000000000000 ]---
[1] https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2FcCyacq1SusUcnAfamULqzkdUA
---
mm/slab_common: fix possible double free of kmem_cache
[ Upstream commit d71608a877362becdc94191f190902fac1e64d35 ]
When doing slub_debug test, kfence's 'test_memcache_typesafe_by_rcu'
kunit test case cause a use-after-free error:
BUG: KASAN: use-after-free in kobject_del+0x14/0x30
Read of size 8 at addr ffff888007679090 by task kunit_try_catch/261
CPU: 1 PID: 261 Comm: kunit_try_catch Tainted: G B N
6.0.0-rc5-next-20220916 #17
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x48
print_address_description.constprop.0+0x87/0x2a5
print_report+0x103/0x1ed
kasan_report+0xb7/0x140
kobject_del+0x14/0x30
kmem_cache_destroy+0x130/0x170
test_exit+0x1a/0x30
kunit_try_run_case+0xad/0xc0
kunit_generic_run_threadfn_adapter+0x26/0x50
kthread+0x17b/0x1b0
</TASK>
The cause is inside kmem_cache_destroy():
kmem_cache_destroy
acquire lock/mutex
shutdown_cache
schedule_work(kmem_cache_release) (if RCU flag set)
release lock/mutex
kmem_cache_release (if RCU flag not set)
In some certain timing, the scheduled work could be run before
the next RCU flag checking, which can then get a wrong value
and lead to double kmem_cache_release().
Fix it by caching the RCU flag inside protected area, just like 'refcnt'
Fixes: 0495e337b703 ("mm/slab_common: Deleting kobject in
kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock")
Signed-off-by: Feng Tang <[email protected]>
Reviewed-by: Hyeonggon Yoo <[email protected]>
Reviewed-by: Waiman Long <[email protected]>
Signed-off-by: Vlastimil Babka <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
## Build
* kernel: 5.19.13-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.19.y
* git commit: 0d49bf6408c47f815c7e056a006617d5431b1bed
* git describe: v5.19.12-102-g0d49bf6408c4
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.19.y/build/v5.19.12-102-g0d49bf6408c4
## No Test Regressions (compared to v5.19.12)
## No Metric Regressions (compared to v5.19.12)
## No Test Fixes (compared to v5.19.12)
## No Metric Fixes (compared to v5.19.12)
## Test result summary
total: 119604, pass: 105318, fail: 1117, skip: 12815, xfail: 354
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 339 total, 336 passed, 3 failed
* arm64: 73 total, 70 passed, 3 failed
* i386: 62 total, 55 passed, 7 failed
* mips: 62 total, 59 passed, 3 failed
* parisc: 14 total, 14 passed, 0 failed
* powerpc: 75 total, 66 passed, 9 failed
* riscv: 32 total, 27 passed, 5 failed
* s390: 26 total, 24 passed, 2 failed
* sh: 26 total, 24 passed, 2 failed
* sparc: 14 total, 14 passed, 0 failed
* x86_64: 66 total, 63 passed, 3 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* 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-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-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
* libgpiod
* 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-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
On Mon, Oct 03, 2022 at 09:09:56AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.19.13 release.
> There are 101 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.1.0).
Tested-by: Bagas Sanjaya <[email protected]>
--
An old man doll... just what I always wanted! - Clara
Hi Greg,
On Mon, Oct 03, 2022 at 09:09:56AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.19.13 release.
> There are 101 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 Wed, 05 Oct 2022 07:07:06 +0000.
> Anything received after that time might be too late.
Build test (gcc version 12.2.1 20220925):
mips: 59 configs -> no failure
arm: 99 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
[1]. https://openqa.qa.codethink.co.uk/tests/1947
[2]. https://openqa.qa.codethink.co.uk/tests/1950
Tested-by: Sudip Mukherjee <[email protected]>
--
Regards
Sudip
Hey Greg,
Ran tests and boot tested on my system, no regressions found
Tested-by: Fenil Jain <[email protected]>
On Tue, Oct 04, 2022 at 12:18:05PM +0530, Naresh Kamboju wrote:
> On Mon, 3 Oct 2022 at 12:43, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.19.13 release.
> > There are 101 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 Wed, 05 Oct 2022 07:07:06 +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.19.13-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.19.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.
>
> Tested-by: Linux Kernel Functional Testing <[email protected]>
>
> NOTE:
> 1) Build warning
> 2) Boot warning on qemu-arm64 with KASAN and Kunit test
> Suspecting one of the recently commits causing this warning and
> need to bisect to confirm the commit id.
> mm/slab_common: fix possible double free of kmem_cache
> [ Upstream commit d71608a877362becdc94191f190902fac1e64d35 ]
Hi Naresh Kamboju,
Thanks for the report!
Could you try reverting the commit and re-test it to confirm?
Also could you provide the kernel dmesg of the failure and the
kernel config of the test?
I locally pulled the linux-stable source and used QEMU to test
it with kasan/kfence enabled, but could not reproduce it (I
only have x86 HW at hand).
> 2) Following kernel boot warning noticed on qemu-arm64 with KASAN and
> KUNIT enabled [1]
>
> [ 177.651182] ------------[ cut here ]------------
> [ 177.652217] kmem_cache_destroy test: Slab cache still has
> objects when called from test_exit+0x28/0x40
> [ 177.654849] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:520
> kmem_cache_destroy+0x1e8/0x20c
> [ 177.666237] Modules linked in:
> [ 177.667325] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B
> 5.19.13-rc1 #1
> [ 177.668666] Hardware name: linux,dummy-virt (DT)
> [ 177.669783] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT
> -SSBS BTYPE=--)
> [ 177.671120] pc : kmem_cache_destroy+0x1e8/0x20c
> [ 177.672217] lr : kmem_cache_destroy+0x1e8/0x20c
> [ 177.691598] Call trace:
> [ 177.692165] kmem_cache_destroy+0x1e8/0x20c
> [ 177.693196] test_exit+0x28/0x40
> [ 177.694158] kunit_catch_run_case+0x5c/0x120
> [ 177.695177] kunit_try_catch_run+0x144/0x26c
> [ 177.696211] kunit_run_case_catch_errors+0x158/0x1e0
> [ 177.697353] kunit_run_tests+0x374/0x750
> [ 177.698333] __kunit_test_suites_init+0x74/0xa0
> [ 177.699386] kunit_run_all_tests+0x160/0x380
> [ 177.700428] kernel_init_freeable+0x32c/0x388
> [ 177.701497] kernel_init+0x2c/0x150
> [ 177.702347] ret_from_fork+0x10/0x20
> [ 177.703308] ---[ end trace 0000000000000000 ]---
>
> [1] https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2FcCyacq1SusUcnAfamULqzkdUA
I also tried the reproduce cmmand from the above link:
tuxrun --runtime podman --device qemu-arm64 --kernel https://builds.tuxbuild.com/2FcCwzbNgR7TlQXzJ0nu32y1CpB/Image.gz --modules https://builds.tuxbuild.com/2FcCwzbNgR7TlQXzJ0nu32y1CpB/modules.tar.xz --rootfs https://storage.lkft.org/rootfs/oe-kirkstone/20220824-114729/juno/lkft-tux-image-juno-20220824120304.rootfs.ext4.gz --parameters SKIPFILE=skipfile-lkft.yaml --image docker.io/lavasoftware/lava-dispatcher:2022.06 --tests kunit --timeouts boot=30
Which also didn't reproduce it, but had some RCU stall problems
(could also be related to the x86 HWs)
[ 321.006279] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 321.007281] ffff0000074c2300: 00 07 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 321.009283] rcu: 0-...0: (1 GPs behind) idle=40f/1/0x4000000000000000 softirq=436/437 fqs=5
[ 321.024995] rcu: rcu_preempt kthread timer wakeup didn't happen for 4464 jiffies! g-207 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
[ 321.026343] rcu: Possible timer handling issue on cpu=1 timer-softirq=1426
[ 321.027340] rcu: rcu_preempt kthread starved for 4465 jiffies! g-207 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1
[ 321.028517] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
[ 321.029488] rcu: RCU grace-period kthread stack dump:
[ 321.030251] task:rcu_preempt state:I stack: 0 pid: 16 ppid: 2 flags:0x00000008
[ 321.031434] Call trace:
[ 321.031878] __switch_to+0x140/0x1e0
[ 321.032565] __schedule+0x4f4/0xc74
[ 321.033228] schedule+0x88/0x13c
[ 321.033915] schedule_timeout+0x104/0x2b0
[ 321.034646] rcu_gp_fqs_loop+0x1a0/0x784
[ 321.035119] rcu_gp_kthread+0x278/0x3a0
[ 321.035608] kthread+0x160/0x170
[ 339.882465] ret_from_fork+0x10/0x20
[ 339.883898] rcu: Stack dump where RCU GP kthread last ran:
The full .xz log is attched.
Thanks,
Feng
On Tue, Oct 04, 2022 at 12:18:05PM +0530, Naresh Kamboju wrote:
> On Mon, 3 Oct 2022 at 12:43, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.19.13 release.
> > There are 101 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 Wed, 05 Oct 2022 07:07:06 +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.19.13-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.19.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
[...]
> 2) Boot warning on qemu-arm64 with KASAN and Kunit test
> Suspecting one of the recently commits causing this warning and
> need to bisect to confirm the commit id.
> mm/slab_common: fix possible double free of kmem_cache
> [ Upstream commit d71608a877362becdc94191f190902fac1e64d35 ]
[...]
> 2) Following kernel boot warning noticed on qemu-arm64 with KASAN and
> KUNIT enabled [1]
>
> [ 177.651182] ------------[ cut here ]------------
> [ 177.652217] kmem_cache_destroy test: Slab cache still has
> objects when called from test_exit+0x28/0x40
> [ 177.654849] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:520
> kmem_cache_destroy+0x1e8/0x20c
> [ 177.666237] Modules linked in:
> [ 177.667325] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B
> 5.19.13-rc1 #1
> [ 177.668666] Hardware name: linux,dummy-virt (DT)
> [ 177.669783] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT
> -SSBS BTYPE=--)
> [ 177.671120] pc : kmem_cache_destroy+0x1e8/0x20c
> [ 177.672217] lr : kmem_cache_destroy+0x1e8/0x20c
> [ 177.673302] sp : ffff8000080876f0
> [ 177.674013] x29: ffff8000080876f0 x28: ffffb5ed1da56f38 x27:
> ffffb5ed1a87b480
> [ 177.676478] x26: ffff800008087aa0 x25: ffff800008087ac8 x24:
> ffff00000c73b480
> [ 177.678215] x23: 000000004c800000 x22: ffffb5ed1eca3000 x21:
> ffffb5ed1da381f0
> [ 177.679873] x20: fdecb5ed18ea3a78 x19: ffff00000759be00 x18:
> 00000000ffffffff
> [ 177.681540] x17: 0000000000000000 x16: 0000000000000000 x15:
> 0000000000000000
> [ 177.683139] x14: 0000000000000000 x13: 206d6f7266206465 x12:
> ffff700001010e63
> [ 177.684776] x11: 1ffff00001010e62 x10: ffff700001010e62 x9 :
> ffffb5ed18b89514
> [ 177.686554] x8 : ffff800008087317 x7 : 0000000000000001 x6 :
> 0000000000000001
> [ 177.688238] x5 : ffffb5ed1d893000 x4 : dfff800000000000 x3 :
> ffffb5ed18b89520
> [ 177.689912] x2 : 0000000000000000 x1 : 0000000000000000 x0 :
> ffff000007150000
> [ 177.691598] Call trace:
> [ 177.692165] kmem_cache_destroy+0x1e8/0x20c
> [ 177.693196] test_exit+0x28/0x40
> [ 177.694158] kunit_catch_run_case+0x5c/0x120
> [ 177.695177] kunit_try_catch_run+0x144/0x26c
> [ 177.696211] kunit_run_case_catch_errors+0x158/0x1e0
> [ 177.697353] kunit_run_tests+0x374/0x750
> [ 177.698333] __kunit_test_suites_init+0x74/0xa0
> [ 177.699386] kunit_run_all_tests+0x160/0x380
> [ 177.700428] kernel_init_freeable+0x32c/0x388
> [ 177.701497] kernel_init+0x2c/0x150
> [ 177.702347] ret_from_fork+0x10/0x20
> [ 177.703308] ---[ end trace 0000000000000000 ]---
>
> [1] https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2FcCyacq1SusUcnAfamULqzkdUA
[+Cc Marco Elver]
I can't reproduce it with the image and still not sure what caused this,
but the dmesg output [3] raises some questions: 1) What made kfence_test fail,
and 2) can a failure from KFENCE test cause this SLUB warning?
2022-10-03T07:48:54.922482 <6>[ 146.564765] ok 3 - test_out_of_bounds_write
2022-10-03T07:48:54.922578 <6>[ 146.577134] # test_out_of_bounds_write-memcache: setup_test_cache: size=32, ctor=0x0
2022-10-03T07:48:54.922666 <6>[ 146.592675] # test_out_of_bounds_write-memcache: test_alloc: size=32, gfp=cc0, policy=left, cache=1
2022-10-03T07:48:54.922756 <3>[ 156.602992] # test_out_of_bounds_write-memcache: ASSERTION FAILED at mm/kfence/kfence_test.c:312
2022-10-03T07:48:54.922844 <3>[ 156.602992] Expected false to be true, but is false
2022-10-03T07:48:54.922934 <3>[ 156.602992]
2022-10-03T07:48:54.923018 <3>[ 156.602992] failed to allocate from KFENCE
2022-10-03T07:48:54.925842 <6>[ 156.864670] not ok 4 - test_out_of_bounds_write-memcache
2022-10-03T07:48:54.926038 <6>[ 156.883110] # test_use_after_free_read: test_alloc: size=32, gfp=cc0, policy=any, cache=0
2022-10-03T07:48:54.926178 <3>[ 156.920306] ==================================================================
[...]
2022-10-03T07:50:11.011619 <6>[ 163.904684] # test_free_bulk-memcache: setup_test_cache: size=223, ctor=0x0
2022-10-03T07:50:11.011811 <6>[ 163.927257] # test_free_bulk-memcache: test_alloc: size=223, gfp=cc0, policy=right, cache=1
2022-10-03T07:50:11.012007 <6>[ 163.992279] # test_free_bulk-memcache: test_alloc: size=223, gfp=cc0, policy=none, cache=1
2022-10-03T07:50:11.012200 <6>[ 164.007799] # test_free_bulk-memcache: test_alloc: size=223, gfp=cc0, policy=left, cache=1
2022-10-03T07:50:11.012392 <3>[ 176.777879] # test_free_bulk-memcache: ASSERTION FAILED at mm/kfence/kfence_test.c:312
2022-10-03T07:50:11.012592 <3>[ 176.777879] Expected false to be true, but is false
2022-10-03T07:50:21.406181 <3>[ 176.777879]
2022-10-03T07:50:21.406483 <3>[ 176.777879] failed to allocate from KFENCE
2022-10-03T07:50:21.406616 <3>[ 177.604811] =============================================================================
2022-10-03T07:50:21.406728 <3>[ 177.608387] BUG test (Tainted: G B ): Objects remaining in test on __kmem_cache_shutdown()
2022-10-03T07:50:21.406827 <3>[ 177.609927] -----------------------------------------------------------------------------
2022-10-03T07:50:21.406918 <3>[ 177.609927]
2022-10-03T07:50:21.407005 <3>[ 177.611424] Slab 0x000000009535baed objects=14 used=1 fp=0x00000000e8649a76 flags=0x3fffc0000000200(slab|node=0|zone=0|lastcpupid=0xffff)
2022-10-03T07:50:21.407112 <4>[ 177.613882] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B 5.19.13-rc1 #1
2022-10-03T07:50:21.407219 <4>[ 177.615231] Hardware name: linux,dummy-virt (DT)
2022-10-03T07:50:21.407310 <4>[ 177.616197] Call trace:
2022-10-03T07:50:21.407400 <4>[ 177.616788] dump_backtrace+0xb8/0x130
2022-10-03T07:50:21.407490 <4>[ 177.617792] show_stack+0x20/0x60
2022-10-03T07:50:21.407581 <4>[ 177.618630] dump_stack_lvl+0x8c/0xb8
2022-10-03T07:50:21.407671 <4>[ 177.619548] dump_stack+0x1c/0x38
2022-10-03T07:50:21.407761 <4>[ 177.620396] slab_err+0xa0/0xf0
2022-10-03T07:50:21.407851 <4>[ 177.621180] __kmem_cache_shutdown+0x140/0x3c0
2022-10-03T07:50:21.407935 <4>[ 177.622230] kmem_cache_destroy+0x9c/0x20c
2022-10-03T07:50:21.408017 <4>[ 177.623242] test_exit+0x28/0x40
2022-10-03T07:50:21.408100 <4>[ 177.624172] kunit_catch_run_case+0x5c/0x120
2022-10-03T07:50:21.408183 <4>[ 177.625189] kunit_try_catch_run+0x144/0x26c
2022-10-03T07:50:21.408269 <4>[ 177.626251] kunit_run_case_catch_errors+0x158/0x1e0
2022-10-03T07:50:21.408355 <4>[ 177.627359] kunit_run_tests+0x374/0x750
2022-10-03T07:50:21.408439 <4>[ 177.628316] __kunit_test_suites_init+0x74/0xa0
2022-10-03T07:50:21.408523 <4>[ 177.629376] kunit_run_all_tests+0x160/0x380
2022-10-03T07:50:21.408606 <4>[ 177.630440] kernel_init_freeable+0x32c/0x388
2022-10-03T07:50:21.408687 <4>[ 177.631517] kernel_init+0x2c/0x150
2022-10-03T07:50:21.408770 <4>[ 177.632351] ret_from_fork+0x10/0x20
2022-10-03T07:50:21.408856 <4>[ 177.633506] Disabling lock debugging due to kernel taint
2022-10-03T07:50:21.408942 <3>[ 177.634724] Object 0x00000000a1747116 @offset=2880
2022-10-03T07:50:21.409029 <4>[ 177.651182] ------------[ cut here ]------------
2022-10-03T07:50:21.409116 <4>[ 177.652217] kmem_cache_destroy test: Slab cache still has objects when called from test_exit+0x28/0x40
2022-10-03T07:50:21.409205 <4>[ 177.654849] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:520 kmem_cache_destroy+0x1e8/0x20c
2022-10-03T07:50:21.409297 <4>[ 177.666237] Modules linked in:
2022-10-03T07:50:32.517549 <4>[ 177.667325] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B 5.19.13-rc1 #1
2022-10-03T07:50:32.518598 <4>[ 177.668666] Hardware name: linux,dummy-virt (DT)
2022-10-03T07:50:32.519060 <4>[ 177.669783] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
2022-10-03T07:50:32.519440 <4>[ 177.671120] pc : kmem_cache_destroy+0x1e8/0x20c
2022-10-03T07:50:32.519798 <4>[ 177.672217] lr : kmem_cache_destroy+0x1e8/0x20c
2022-10-03T07:50:32.520150 <4>[ 177.673302] sp : ffff8000080876f0
2022-10-03T07:50:32.520502 <4>[ 177.674013] x29: ffff8000080876f0 x28: ffffb5ed1da56f38 x27: ffffb5ed1a87b480
2022-10-03T07:50:32.520852 <4>[ 177.676478] x26: ffff800008087aa0 x25: ffff800008087ac8 x24: ffff00000c73b480
2022-10-03T07:50:32.521203 <4>[ 177.678215] x23: 000000004c800000 x22: ffffb5ed1eca3000 x21: ffffb5ed1da381f0
2022-10-03T07:50:32.521565 <4>[ 177.679873] x20: fdecb5ed18ea3a78 x19: ffff00000759be00 x18: 00000000ffffffff
2022-10-03T07:50:32.521903 <4>[ 177.681540] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
2022-10-03T07:50:32.522248 <4>[ 177.683139] x14: 0000000000000000 x13: 206d6f7266206465 x12: ffff700001010e63
2022-10-03T07:50:32.522624 <4>[ 177.684776] x11: 1ffff00001010e62 x10: ffff700001010e62 x9 : ffffb5ed18b89514
2022-10-03T07:50:32.522978 <4>[ 177.686554] x8 : ffff800008087317 x7 : 0000000000000001 x6 : 0000000000000001
2022-10-03T07:50:32.523346 <4>[ 177.688238] x5 : ffffb5ed1d893000 x4 : dfff800000000000 x3 : ffffb5ed18b89520
2022-10-03T07:50:32.523706 <4>[ 177.689912] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007150000
2022-10-03T07:50:32.524060 <4>[ 177.691598] Call trace:
2022-10-03T07:50:32.524419 <4>[ 177.692165] kmem_cache_destroy+0x1e8/0x20c
2022-10-03T07:50:32.524781 <4>[ 177.693196] test_exit+0x28/0x40
2022-10-03T07:50:32.525138 <4>[ 177.694158] kunit_catch_run_case+0x5c/0x120
2022-10-03T07:50:32.525491 <4>[ 177.695177] kunit_try_catch_run+0x144/0x26c
2022-10-03T07:50:32.525842 <4>[ 177.696211] kunit_run_case_catch_errors+0x158/0x1e0
2022-10-03T07:50:32.526203 <4>[ 177.697353] kunit_run_tests+0x374/0x750
2022-10-03T07:50:32.526583 <4>[ 177.698333] __kunit_test_suites_init+0x74/0xa0
2022-10-03T07:50:32.526944 <4>[ 177.699386] kunit_run_all_tests+0x160/0x380
2022-10-03T07:50:32.527319 <4>[ 177.700428] kernel_init_freeable+0x32c/0x388
2022-10-03T07:50:32.527677 <4>[ 177.701497] kernel_init+0x2c/0x150
2022-10-03T07:50:32.528045 <4>[ 177.702347] ret_from_fork+0x10/0x20
2022-10-03T07:50:32.528415 <4>[ 177.703308] ---[ end trace 0000000000000000 ]---
2022-10-03T07:50:32.528777 <6>[ 180.045230] not ok 14 - test_free_bulk-memcache
[3] https://tuxapi-prod-storage-public-linaro.s3.amazonaws.com/lkft/tests/2FcCyacq1SusUcnAfamULqzkdUA/logs.html?AWSAccessKeyId=ASIA4PEBGJPLJ3MHQBGO&Signature=%2FlJHsH06tzBXzSyMCaDjWaTG%2F9o%3D&x-amz-security-token=IQoJb3JpZ2luX2VjEBoaCXVzLWVhc3QtMSJHMEUCIQD4TKWLb%2B8aAYVTlrta0n5XyR9BsgwaUXE46EgOgqjuIQIgXIMnwwIUUqYAkt86EjRR0kCmWx8E9iuRgYvoqC2yEyYqjQMI0%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FARACGgw4NTcxMTY5MjA3OTAiDLYObfq5JIo0d4obbSrhAmrI7gL9QgdUI5D%2BN1Rh7sCX9meh0FAVldxj06oK5BHlily6x7rI0m7oJNlD3P31xSxDHUhBgPE3qiQj0XVBORvURqUuf5jHKEWuSO%2BqWGWYKPZLECeRUlMl4JXq5fI5FjWMU9VRsHrZDqZhV25z2i8jtjsOWsHWiNvyhhN1am2eYQUMmVnLhoEgLDhgSj4k72%2BJnczrPYpgcbJ1L%2BUlwNUT9nMdRV6oYAbJVeQeUp66n%2FJ4AvPZzlm3BhaCjvoJhI4dmB99papGw4IhdTdfbqkKvOyIR6gRDYxKiXPmU1EKgNEcWUQU9e9ILLOJh%2BgEH9Sad8ObcQtR4L91o%2B%2B6eZasaga%2F9GvBj1pr7YYpRCVmkOGs1Edw22NKSDAtmf1qiI2ShVoqW3VkvXSIClq5VNTZBjMKi9P5x005XdCqXxZ8Iug07v%2FolQ1ee4naCCXbbYEa10YjLkkBYk0gXujugT2wMKOp9ZkGOp4BfdXurWMFtd5rU4pfcZewiMwwM4h%2FXlUqGOIGkaps7RLxPQ4e1vmMPoKiU16a3kWxR6ZC0IuDEwMyU2Cr13UxEAY%2B5nBjYv2iFzGinJwM9OEhLcOkizY%2F6y0o6hLg%2Fqd5jflTqMjPRkbhtVoH2W%2BnBZkPUvRgjDU6%2FRC7Tb0iiIpGw7pqRHJpnzxtzQzsUU%2Bd5FL4OAGxKQDR9Dbjzt0%3D&Expires=1664967348
> ---
> mm/slab_common: fix possible double free of kmem_cache
> [ Upstream commit d71608a877362becdc94191f190902fac1e64d35 ]
>
> When doing slub_debug test, kfence's 'test_memcache_typesafe_by_rcu'
> kunit test case cause a use-after-free error:
>
> BUG: KASAN: use-after-free in kobject_del+0x14/0x30
> Read of size 8 at addr ffff888007679090 by task kunit_try_catch/261
>
> CPU: 1 PID: 261 Comm: kunit_try_catch Tainted: G B N
> 6.0.0-rc5-next-20220916 #17
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
> 04/01/2014
> Call Trace:
> <TASK>
> dump_stack_lvl+0x34/0x48
> print_address_description.constprop.0+0x87/0x2a5
> print_report+0x103/0x1ed
> kasan_report+0xb7/0x140
> kobject_del+0x14/0x30
> kmem_cache_destroy+0x130/0x170
> test_exit+0x1a/0x30
> kunit_try_run_case+0xad/0xc0
> kunit_generic_run_threadfn_adapter+0x26/0x50
> kthread+0x17b/0x1b0
> </TASK>
>
> The cause is inside kmem_cache_destroy():
>
> kmem_cache_destroy
> acquire lock/mutex
> shutdown_cache
> schedule_work(kmem_cache_release) (if RCU flag set)
> release lock/mutex
> kmem_cache_release (if RCU flag not set)
>
> In some certain timing, the scheduled work could be run before
> the next RCU flag checking, which can then get a wrong value
> and lead to double kmem_cache_release().
>
> Fix it by caching the RCU flag inside protected area, just like 'refcnt'
>
> Fixes: 0495e337b703 ("mm/slab_common: Deleting kobject in
> kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock")
> Signed-off-by: Feng Tang <[email protected]>
> Reviewed-by: Hyeonggon Yoo <[email protected]>
> Reviewed-by: Waiman Long <[email protected]>
> Signed-off-by: Vlastimil Babka <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
>
>
> ## Build
> * kernel: 5.19.13-rc1
> * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
> * git branch: linux-5.19.y
> * git commit: 0d49bf6408c47f815c7e056a006617d5431b1bed
> * git describe: v5.19.12-102-g0d49bf6408c4
> * test details:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.19.y/build/v5.19.12-102-g0d49bf6408c4
[...]
> --
> Linaro LKFT
> https://lkft.linaro.org
--
Thanks,
Hyeonggon
On Wed, 5 Oct 2022 at 15:09, Feng Tang <[email protected]> wrote:
>
> On Tue, Oct 04, 2022 at 12:18:05PM +0530, Naresh Kamboju wrote:
> > On Mon, 3 Oct 2022 at 12:43, Greg Kroah-Hartman
> > <[email protected]> wrote:
> > >
> > > This is the start of the stable review cycle for the 5.19.13 release.
> > > There are 101 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 Wed, 05 Oct 2022 07:07:06 +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.19.13-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.19.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.
> >
> > Tested-by: Linux Kernel Functional Testing <[email protected]>
> >
> > NOTE:
> > 1) Build warning
> > 2) Boot warning on qemu-arm64 with KASAN and Kunit test
> > Suspecting one of the recently commits causing this warning and
> > need to bisect to confirm the commit id.
> > mm/slab_common: fix possible double free of kmem_cache
> > [ Upstream commit d71608a877362becdc94191f190902fac1e64d35 ]
>
> Hi Naresh Kamboju,
>
> Thanks for the report!
>
> Could you try reverting the commit and re-test it to confirm?
Anders re-run the tests multiple times with and without the patch reverted and
was not successful in reproducing the reported problem.
Which confirms that, it is not easy to reproduce.
> Also could you provide the kernel dmesg of the failure and the
> kernel config of the test?
dmesg log attached to this email.
Here is the build link,
https://builds.tuxbuild.com/2FcCwzbNgR7TlQXzJ0nu32y1CpB/
>
> I locally pulled the linux-stable source and used QEMU to test
> it with kasan/kfence enabled, but could not reproduce it (I
> only have x86 HW at hand).
>
> > 2) Following kernel boot warning noticed on qemu-arm64 with KASAN and
> > KUNIT enabled [1]
> >
> > [ 177.651182] ------------[ cut here ]------------
> > [ 177.652217] kmem_cache_destroy test: Slab cache still has
> > objects when called from test_exit+0x28/0x40
> > [ 177.654849] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:520
> > kmem_cache_destroy+0x1e8/0x20c
> > [ 177.666237] Modules linked in:
> > [ 177.667325] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B
> > 5.19.13-rc1 #1
> > [ 177.668666] Hardware name: linux,dummy-virt (DT)
> > [ 177.669783] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT
> > -SSBS BTYPE=--)
> > [ 177.671120] pc : kmem_cache_destroy+0x1e8/0x20c
> > [ 177.672217] lr : kmem_cache_destroy+0x1e8/0x20c
> > [ 177.691598] Call trace:
> > [ 177.692165] kmem_cache_destroy+0x1e8/0x20c
> > [ 177.693196] test_exit+0x28/0x40
> > [ 177.694158] kunit_catch_run_case+0x5c/0x120
> > [ 177.695177] kunit_try_catch_run+0x144/0x26c
> > [ 177.696211] kunit_run_case_catch_errors+0x158/0x1e0
> > [ 177.697353] kunit_run_tests+0x374/0x750
> > [ 177.698333] __kunit_test_suites_init+0x74/0xa0
> > [ 177.699386] kunit_run_all_tests+0x160/0x380
> > [ 177.700428] kernel_init_freeable+0x32c/0x388
> > [ 177.701497] kernel_init+0x2c/0x150
> > [ 177.702347] ret_from_fork+0x10/0x20
> > [ 177.703308] ---[ end trace 0000000000000000 ]---
> >
> > [1] https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2FcCyacq1SusUcnAfamULqzkdUA
>
> I also tried the reproduce cmmand from the above link:
>
> tuxrun --runtime podman --device qemu-arm64 --kernel https://builds.tuxbuild.com/2FcCwzbNgR7TlQXzJ0nu32y1CpB/Image.gz --modules https://builds.tuxbuild.com/2FcCwzbNgR7TlQXzJ0nu32y1CpB/modules.tar.xz --rootfs https://storage.lkft.org/rootfs/oe-kirkstone/20220824-114729/juno/lkft-tux-image-juno-20220824120304.rootfs.ext4.gz --parameters SKIPFILE=skipfile-lkft.yaml --image docker.io/lavasoftware/lava-dispatcher:2022.06 --tests kunit --timeouts boot=30
>
> Which also didn't reproduce it, but had some RCU stall problems
> (could also be related to the x86 HWs)
>
> [ 321.006279] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 321.007281] ffff0000074c2300: 00 07 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 321.009283] rcu: 0-...0: (1 GPs behind) idle=40f/1/0x4000000000000000 softirq=436/437 fqs=5
>
> [ 321.024995] rcu: rcu_preempt kthread timer wakeup didn't happen for 4464 jiffies! g-207 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
> [ 321.026343] rcu: Possible timer handling issue on cpu=1 timer-softirq=1426
> [ 321.027340] rcu: rcu_preempt kthread starved for 4465 jiffies! g-207 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1
> [ 321.028517] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
> [ 321.029488] rcu: RCU grace-period kthread stack dump:
> [ 321.030251] task:rcu_preempt state:I stack: 0 pid: 16 ppid: 2 flags:0x00000008
> [ 321.031434] Call trace:
> [ 321.031878] __switch_to+0x140/0x1e0
> [ 321.032565] __schedule+0x4f4/0xc74
> [ 321.033228] schedule+0x88/0x13c
> [ 321.033915] schedule_timeout+0x104/0x2b0
> [ 321.034646] rcu_gp_fqs_loop+0x1a0/0x784
> [ 321.035119] rcu_gp_kthread+0x278/0x3a0
> [ 321.035608] kthread+0x160/0x170
> [ 339.882465] ret_from_fork+0x10/0x20
> [ 339.883898] rcu: Stack dump where RCU GP kthread last ran:
>
> The full .xz log is attched.
Thanks for looking into this.
>
> Thanks,
> Feng
- Naresh