[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8c64075e-1cb6-4090-95b1-9c7a6b45eaad@roeck-us.net>
Date: Mon, 13 Jan 2025 08:40:11 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 6.13-rc7
On Sun, Jan 12, 2025 at 03:19:29PM -0800, Linus Torvalds wrote:
> Well, it looked a bit quiet at the start of the week, but then things
> picked up, and we're definitely back to speed after the two quiet
> holiday weeks.
>
> This rc7 is slightly bigger than normal, but considering the timing,
> it's pretty much where I would have expected, and nothing really
> stands out. The diffstat looks fine, and the appended shortlog doesn't
> look strange either.
>
No surprises in my testing.
Build results:
total: 161 pass: 161 fail: 0
Qemu test results:
total: 544 pass: 544 fail: 0
Unit test results:
pass: 470845 fail: 0
Previously reported warnings are still there. I attached them below
for reference, including those introduced in earlier kernel releases.
Guenter
---
New in v6.13-rc:
sparc64 boot tests:
[ 0.752745] =============================
[ 0.752953] [ BUG: Invalid wait context ]
[ 0.753233] 6.13.0-rc7 #1 Not tainted
[ 0.753489] -----------------------------
[ 0.753696] swapper/0/1 is trying to lock:
[ 0.753921] 0000000001b81558 (pci_poke_lock){....}-{3:3}, at: pci_config_read16+0x8/0x80
[ 0.754500] other info that might help us debug this:
[ 0.754734] context-{5:5}
[ 0.754943] 2 locks held by swapper/0/1:
[ 0.755165] #0: fffff800042b50f8 (&dev->mutex){....}-{4:4}, at: __driver_attach+0x80/0x160
[ 0.755460] #1: 0000000001d41930 (pci_lock){....}-{2:2}, at: pci_bus_read_config_word+0x18/0x80
[ 0.755748] stack backtrace:
[ 0.756011] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.0-rc7 #1
[ 0.756344] Call Trace:
[ 0.756580] [<0000000000500630>] __lock_acquire+0xa50/0x3160
[ 0.756817] [<0000000000503848>] lock_acquire+0xe8/0x340
[ 0.757035] [<0000000001101ebc>] _raw_spin_lock_irqsave+0x3c/0x80
[ 0.757265] [<00000000004600c8>] pci_config_read16+0x8/0x80
[ 0.757486] [<0000000000460ccc>] sun4u_read_pci_cfg+0x12c/0x1a0
[ 0.757711] [<0000000000b9f59c>] pci_bus_read_config_word+0x3c/0x80
[ 0.757939] [<0000000000ba8a98>] pci_find_capability+0x18/0xa0
[ 0.758165] [<0000000000ba2590>] set_pcie_port_type+0x10/0x160
[ 0.758388] [<000000000045f338>] pci_of_scan_bus+0x158/0xb00
[ 0.758610] [<0000000000428c98>] pci_scan_one_pbm+0xd0/0xf8
[ 0.758831] [<0000000000462a14>] sabre_probe+0x1f4/0x5c0
Fix is queued in -next.
---
Backtraces introduced in earlier kernels follow. I am not aware of
attempts to fix the problems. I am reporting those only for completeness.
arm64, when testing gfs2:
[ 23.170467] WARNING: CPU: 1 PID: 2585 at include/linux/backing-dev.h:251 __folio_mark_dirty+0x310/0x384
...
[ 23.173117] Call trace:
[ 23.173234] __folio_mark_dirty+0x310/0x384 (P)
[ 23.173349] mark_buffer_dirty+0x8c/0x198
[ 23.173423] gfs2_unpin+0x6c/0x420
[ 23.173480] buf_lo_after_commit+0x6c/0x90
[ 23.173539] gfs2_log_flush+0x3a0/0xcd4
[ 23.173595] gfs2_kill_sb+0x3c/0x200
There are many other similar warning backtraces. Affects arm64 (and probably
other) architectures when testing gfs2 with CONFIG_LOCKDEP enabled. Seen since
at least v5.15.
---
ppc, when running the mpc8544ds emulation with mpc85xx_smp_defconfig:
LSM: initializing lsm=lockdown,capability,landlock,yama,loadpin,safesetid,ipe
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/smp.c:807 smp_call_function_many_cond+0x4fc/0xa38
Modules linked in:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc6-00345-g41374bc033d2 #1
Hardware name: MPC8544DS e500v2 0x80210030 MPC8544 DS
NIP: c0185a8c LR: c0186014 CTR: 00000000
REGS: c2691d40 TRAP: 0700 Not tainted (6.13.0-rc6-00345-g41374bc033d2)
MSR: 00021000 <CE,ME> CR: 24004288 XER: 20000000
GPR00: c002355c c2691e30 c255f5c0 c26a84e4 00000000 00000000 00000001 c26b0000
GPR08: 00000000 00000003 c26b0000 00000000 84004288 020a7f18 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 c0000000 00000001 00000000 cfdf1fe0
GPR24: c0186014 c26a84e4 c00234fc 00000000 00000000 00029000 4bffd2d8 00000000
NIP [c0185a8c] smp_call_function_many_cond+0x4fc/0xa38
LR [c0186014] smp_call_function+0x3c/0x58
Call Trace:
[c2691e30] [c07af900] __SCT__lsm_static_call_capable_0+0x0/0x20 (unreliable)
[c2691e90] [24002288] 0x24002288
[c2691ea0] [c002355c] flush_tlb_kernel_range+0x2c/0x50
[c2691eb0] [c0024b6c] patch_mem.constprop.0+0x108/0x1b0
[c2691ed0] [c00198ac] arch_static_call_transform+0x10c/0x150
[c2691ef0] [c2036ba4] security_add_hooks+0x138/0x24c
[c2691f20] [c20359a8] capability_init+0x24/0x38
[c2691f30] [c2035eb8] initialize_lsm+0x48/0x90
[c2691f50] [c2036798] security_init+0x2e0/0x5b4
[c2691fa0] [c20010ec] start_kernel+0x5d4/0x81c
[c2691ff0] [c0000478] set_ivor+0x150/0x18c
Seen since v6.12. I think it is due to CONFIG_SECURITY_IPE, but bisect
attempts have been elusive.
Powered by blists - more mailing lists