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... 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 gregkh@linuxfoundation.org Linux 5.19.13-rc1
Levi Yun ppbuk5246@gmail.com damon/sysfs: fix possible memleak on damon_sysfs_add_target
Nadav Amit namit@vmware.com x86/alternative: Fix race in try_get_desc()
Borislav Petkov bp@suse.de x86/cacheinfo: Add a cpu_llc_shared_mask() UP variant
Jim Mattson jmattson@google.com KVM: x86: Hide IA32_PLATFORM_DCA_CAP[31:0] from the guest
Arnaldo Carvalho de Melo acme@redhat.com perf tests record: Fail the test if the 'errs' counter is not zero
Zhengjun Xing zhengjun.xing@linux.intel.com perf test: Fix test case 87 ("perf record tests") for hybrid systems
Daniel Golle daniel@makrotopia.org net: ethernet: mtk_eth_soc: fix mask of RX_DMA_GET_SPORT{,_V2}
Vladimir Oltean vladimir.oltean@nxp.com net: mscc: ocelot: fix tagged VLAN refusal while under a VLAN-unaware bridge
Peng Fan peng.fan@nxp.com clk: imx93: drop of_match_ptr
Florian Fainelli f.fainelli@gmail.com clk: iproc: Do not rely on node name for correct PLL setup
Ashutosh Dixit ashutosh.dixit@intel.com drm/i915/gt: Perf_limit_reasons are only available for Gen11+
Han Xu han.xu@nxp.com clk: imx: imx6sx: remove the SET_RATE_PARENT flag for QSPI clocks
Al Viro viro@zeniv.linux.org.uk don't use __kernel_write() on kmap_local_page()
Eli Cohen elic@nvidia.com vdpa/mlx5: Fix MQ to support non power of two num queues
Suwan Kim suwan.kim027@gmail.com virtio-blk: Fix WARN_ON_ONCE in virtio_queue_rq()
Angus Chen angus.chen@jaguarmicro.com vdpa/ifcvf: fix the calculation of queuepair
Maciej Fijalkowski maciej.fijalkowski@intel.com ice: xsk: drop power of 2 ring size restriction for AF_XDP
Maciej Fijalkowski maciej.fijalkowski@intel.com ice: xsk: change batched Tx descriptor cleaning
Wang Yufen wangyufen@huawei.com selftests: Fix the if conditions of in test_extra_filter()
Lukas Wunner lukas@wunner.de net: phy: Don't WARN for PHY_UP state in mdio_bus_phy_resume()
Junxiao Chang junxiao.chang@intel.com net: stmmac: power up/down serdes in stmmac_open/release
Paweł Lenkow pawel.lenkow@camlingroup.com wifi: mac80211: fix memory corruption in minstrel_ht_update_rates()
Hans de Goede hdegoede@redhat.com wifi: mac80211: fix regression with non-QoS drivers
Tamizh Chelvam Raja quic_tamizhr@quicinc.com wifi: cfg80211: fix MCS divisor value
Michael Kelley mikelley@microsoft.com nvme: Fix IOC_PR_CLEAR and IOC_PR_RELEASE ioctls for nvme devices
Peng Wu wupeng58@huawei.com net/mlxbf_gige: Fix an IS_ERR() vs NULL bug in mlxbf_gige_mdio_probe
Rafael Mendonca rafaelmendsr@gmail.com cxgb4: fix missing unlock on ETHOFLD desc collect fail path
Hangyu Hua hbh25y@gmail.com net: sched: act_ct: fix possible refcount leak in tcf_ct_init()
Peilin Ye peilin.ye@bytedance.com usbnet: Fix memory leak in usbnet_disconnect()
Zhengjun Xing zhengjun.xing@linux.intel.com perf parse-events: Remove "not supported" hybrid cache events
Zhengjun Xing zhengjun.xing@linux.intel.com perf print-events: Fix "perf list" can not display the PMU prefix for some hybrid cache events
Ian Rogers irogers@google.com perf parse-events: Break out tracepoint and printing
Pali Rohár pali@kernel.org gpio: mvebu: Fix check for pwm support on non-A8K platforms
Yang Yingliang yangyingliang@huawei.com Input: melfas_mip4 - fix return value check in mip4_probe()
Brian Norris briannorris@chromium.org Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time"
Radhey Shyam Pandey radhey.shyam.pandey@amd.com net: macb: Fix ZynqMP SGMII non-wakeup source resume failure
Francesco Dolcini francesco.dolcini@toradex.com drm/bridge: lt8912b: fix corrupted image output
Philippe Schenker philippe.schenker@toradex.com drm/bridge: lt8912b: set hdmi or dvi mode
Philippe Schenker philippe.schenker@toradex.com drm/bridge: lt8912b: add vsync hsync
Martin Povišer povik+lin@cutebit.org ASoC: tas2770: Reinit regcache on reset
Johan Hovold johan+linaro@kernel.org arm64: dts: qcom: sm8350: fix UFS PHY serdes size
Conor Dooley conor.dooley@microchip.com clk: microchip: mpfs: make the rtc's ahb clock critical
Conor Dooley conor.dooley@microchip.com clk: microchip: mpfs: fix clk_cfg array bounds violation
Shengjiu Wang shengjiu.wang@nxp.com ASoC: imx-card: Fix refcount issue with of_node_put
Samuel Holland samuel@sholland.org soc: sunxi: sram: Fix debugfs info for A64 SRAM C
Samuel Holland samuel@sholland.org soc: sunxi: sram: Fix probe function ordering issues
Samuel Holland samuel@sholland.org soc: sunxi: sram: Prevent the driver from being unbound
Samuel Holland samuel@sholland.org soc: sunxi: sram: Actually claim SRAM regions
Romain Naour romain.naour@skf.com ARM: dts: am5748: keep usb4_tm disabled
Richard Zhu hongxing.zhu@nxp.com reset: imx7: Fix the iMX8MP PCIe PHY PERST support
YuTong Chang mtwget@gmail.com ARM: dts: am33xx: Fix MMCHS0 dma properties
Hans Verkuil hverkuil-cisco@xs4all.nl media: v4l2-compat-ioctl32.c: zero buffer passed to v4l2_compat_get_array_args()
Nícolas F. R. A. Prado nfraprado@collabora.com media: mediatek: vcodec: Drop platform_get_resource(IORESOURCE_IRQ)
Nicolas Dufresne nicolas.dufresne@collabora.com media: rkvdec: Disable H.264 error detection
Hangyu Hua hbh25y@gmail.com media: dvb_vb2: fix possible out of bound access
Shuai Xue xueshuai@linux.alibaba.com mm,hwpoison: check mm when killing accessing process
Doug Berger opendmb@gmail.com mm/hugetlb: correct demote page offset logic
Sergei Antonov saproj@gmail.com mm: bring back update_mmu_cache() to finish_fault()
Minchan Kim minchan@kernel.org mm: fix madivse_pageout mishandling on non-LRU page
Alistair Popple apopple@nvidia.com mm/migrate_device.c: copy pte dirty bit to page
Alistair Popple apopple@nvidia.com mm/migrate_device.c: add missing flush_cache_page()
Alistair Popple apopple@nvidia.com mm/migrate_device.c: flush TLB while holding PTL
Binyi Han dantengknight@gmail.com mm: fix dereferencing possible ERR_PTR
Zi Yan ziy@nvidia.com mm/page_isolation: fix isolate_single_pageblock() isolation behavior
Maurizio Lombardi mlombard@redhat.com mm: prevent page_frag_alloc() from corrupting the memory
Mel Gorman mgorman@techsingularity.net mm/page_alloc: fix race condition between build_all_zonelists and page allocation
Yang Shi shy828301@gmail.com mm: gup: fix the fast GUP race against THP collapse
Wenchao Chen wenchao.chen@unisoc.com mmc: hsq: Fix data stomping during mmc recovery
Sergei Antonov saproj@gmail.com mmc: moxart: fix 4-bit bus width and remove 8-bit bus width
Menglong Dong imagedong@tencent.com mptcp: fix unreleased socket in accept queue
Menglong Dong imagedong@tencent.com mptcp: factor out __mptcp_close() without socket lock
Florian Westphal fw@strlen.de mm: fix BUG splat with kvmalloc + GFP_ATOMIC
Niklas Cassel niklas.cassel@wdc.com libata: add ATA_HORKAGE_NOLPM for Pioneer BDR-207M and BDR-205
Maxime Coquelin maxime.coquelin@redhat.com vduse: prevent uninitialized memory accesses
Bokun Zhang Bokun.Zhang@amd.com drm/amdgpu: Add amdgpu suspend-resume code path under SRIOV
Chris Wilson chris@chris-wilson.co.uk drm/i915/gt: Restrict forced preemption to the active context
Yang Shi shy828301@gmail.com powerpc/64s/radix: don't need to broadcast IPI for radix pmd collapse flush
Ulf Hansson ulf.hansson@linaro.org Revert "firmware: arm_scmi: Add clock management to the SCMI power domain"
Alexander Couzens lynxis@fe80.eu net: mt7531: only do PLL once after the reset
Greg Kroah-Hartman gregkh@linuxfoundation.org mm/damon/dbgfs: fix memory leak when using debugfs_lookup()
Kees Cook keescook@chromium.org x86/uaccess: avoid check_object_size() in copy_from_user_nmi()
ChenXiaoSong chenxiaosong2@huawei.com ntfs: fix BUG_ON in ntfs_lookup_inode_by_name()
Linus Walleij linus.walleij@linaro.org ARM: dts: integrator: Tag PCI host with device_type
Christoph Hellwig hch@lst.de frontswap: don't call ->init if no ops are registered
Jarkko Sakkinen jarkko@kernel.org x86/sgx: Do not fail on incomplete sanitization on premature stop of ksgxd
Alexander Wetzel alexander@wetzel-home.de wifi: mac80211: ensure vif queues are operational after start
Aidan MacDonald aidanmacdonald.0x0@gmail.com clk: ingenic-tcu: Properly enable registers before accessing timers
Marc Kleine-Budde mkl@pengutronix.de can: c_can: don't cache TX messages for C_CAN cores
Sebastian Krzyszkowiak sebastian.krzyszkowiak@puri.sm Input: snvs_pwrkey - fix SNVS_HPVIDR1 register address
Frank Wunderlich frank-w@public-files.de net: usb: qmi_wwan: Add new usb-id for Dell branded EM7455
Mario Limonciello mario.limonciello@amd.com thunderbolt: Explicitly reset plug events delay back to USB4 spec value
Heikki Krogerus heikki.krogerus@linux.intel.com usb: typec: ucsi: Remove incorrect warning
Hongling Zeng zenghongling@kylinos.cn uas: ignore UAS for Thinkplus chips
Hongling Zeng zenghongling@kylinos.cn usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS
Hongling Zeng zenghongling@kylinos.cn uas: add no-uas quirk for Hiksemi usb_disk
William Breathitt Gray william.gray@linaro.org counter: 104-quad-8: Fix skipped IRQ lines during events configuration
William Breathitt Gray william.gray@linaro.org counter: 104-quad-8: Implement and utilize register structures
William Breathitt Gray william.gray@linaro.org counter: 104-quad-8: Utilize iomap interface
Adrian Hunter adrian.hunter@intel.com perf record: Fix cpu mask bit setting for mixed mmaps
Athira Rajeev atrajeev@linux.vnet.ibm.com tools/perf: Fix out of bound access to cpu mask array
Heiko Stuebner heiko@sntech.de 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(-)
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 linux@roeck-us.net
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... 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 f.fainelli@gmail.com
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... 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 jforbes@fedoraproject.org
On Oct 3, 2022, at 3:09 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org 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.
5.19.13-rc1 compiled and booted with no errors or regressions on my x86_64 test system.
Tested-by: Slade Watkins srw@sladewatkins.net
-srw
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... 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 skhan@linuxfoundation.org
thanks, -- Shuah
On Mon, Oct 3, 2022 at 8:56 AM Greg Kroah-Hartman gregkh@linuxfoundation.org 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... 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 zanaziz313@gmail.com
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... 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 re@w6rz.net
On Mon, 3 Oct 2022 at 12:43, Greg Kroah-Hartman gregkh@linuxfoundation.org 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... 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 lkft@linaro.org
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/2FcCyacq1Su...
--- 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 feng.tang@intel.com Reviewed-by: Hyeonggon Yoo 42.hyeyoo@gmail.com Reviewed-by: Waiman Long longman@redhat.com Signed-off-by: Vlastimil Babka vbabka@suse.cz Signed-off-by: Sasha Levin sashal@kernel.org
## 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....
## 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 Tue, Oct 04, 2022 at 12:18:05PM +0530, Naresh Kamboju wrote:
On Mon, 3 Oct 2022 at 12:43, Greg Kroah-Hartman gregkh@linuxfoundation.org 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... 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 lkft@linaro.org
NOTE:
- Build warning
- 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).
- 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 hasobjects 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/2FcCyacq1Su...
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-i... --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 Wed, 5 Oct 2022 at 15:09, Feng Tang feng.tang@intel.com 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 gregkh@linuxfoundation.org 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... 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 lkft@linaro.org
NOTE:
- Build warning
- 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).
- 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 hasobjects 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/2FcCyacq1Su...
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-i... --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
On Tue, Oct 04, 2022 at 12:18:05PM +0530, Naresh Kamboju wrote:
On Mon, 3 Oct 2022 at 12:43, Greg Kroah-Hartman gregkh@linuxfoundation.org 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... 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
[...]
- 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 ]
[...]
- 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 hasobjects 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/2FcCyacq1Su...
[+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/2FcCya...
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 feng.tang@intel.com Reviewed-by: Hyeonggon Yoo 42.hyeyoo@gmail.com Reviewed-by: Waiman Long longman@redhat.com Signed-off-by: Vlastimil Babka vbabka@suse.cz Signed-off-by: Sasha Levin sashal@kernel.org
## 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....
[...]
-- 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 bagasdotme@gmail.com
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 sudip.mukherjee@codethink.co.uk
-- Regards Sudip
-
Bagas Sanjaya -
Feng Tang -
Florian Fainelli -
Greg Kroah-Hartman -
Guenter Roeck -
Hyeonggon Yoo -
Justin Forbes -
Naresh Kamboju -
Ron Economos -
Shuah Khan -
Slade Watkins -
Sudip Mukherjee (Codethink) -
Zan Aziz