On Tue, Dec 10, 2024 at 11:27:19AM +0000, Mark Rutland wrote: > On Mon, Dec 09, 2024 at 11:37:12AM +0000, Mark Rutland wrote: > > Hi Kent, > > > > On Thu, Dec 05, 2024 at 01:04:59PM -0500, Kent Overstreet wrote: > > > On 6.13-rc1, I'm now seeing a ton of test failures due to this warning - > > > what gives? > > > > Sorry about this; I just sent what I *thought* was a fix for this: > > > > > > https://lore.kernel.org/linux-arm-kernel/[email protected]/ > > > > ... but re-reading the below I see you're actually hitting a different > > issue. > > > > > 00104 ========= TEST generic/017 > > > 00104 run fstests generic/017 at 2024-12-05 11:47:43 > > > 00104 spectre-v4 mitigation disabled by command-line option > > > 00106 bcachefs (vdc): starting version 1.13: inode_has_child_snapshots > > > 00106 bcachefs (vdc): initializing new filesystem > > > 00106 bcachefs (vdc): going read-write > > > 00106 bcachefs (vdc): marking superblocks > > > 00106 bcachefs (vdc): initializing freespace > > > 00106 bcachefs (vdc): done initializing freespace > > > 00106 bcachefs (vdc): reading snapshots table > > > 00106 bcachefs (vdc): reading snapshots done > > > 00106 bcachefs (vdc): done starting filesystem > > > 00200 ------------[ cut here ]------------ > > > 00200 WARNING: CPU: 8 PID: 12571 at arch/arm64/kernel/stacktrace.c:223 > > > arch_stack_walk+0x2c0/0x388 > > > > Looking at v6.13-rc1, that's the warning in > > kunwind_next_frame_record_meta() for when the frame_record_meta::type is > > not a valid value, which likely implies one of the following: > > > > (a) The logic to identify a frame_record_meta is wrong. > > > > (b) The entry logic has failed to initilialize pt_regs::stackframe::meta > > on an entry path somehow. > > > > (c) The stack has been corrupted, and some frame record has been > > clobbered to look like a frame_record_meta. > > Looking some more, I see that bch2_btree_transactions_read() is trying > to unwind other tasks, and I believe what's happening here is that the > unwindee isn't actually blocked for the duration of the unwind, leading > to the unwinder encountering junk and consequently producing the > warning. > > As a test case, it's possible to trigger similar with a few parallel > instances of: > > while true; do cat /proc/*/stack > /dev/null > > The only thing we can do on the arm64 side is remove the WARN_ON_ONCE(), > which'll get rid of the splat. It seems we've never been unlucky enough > to hit a stale fgraph entry, or that would've blown up also. > > Regardless of the way arm64 behaves here, the unwind performed by > bch2_btree_transactions_read() is going to contain garbage unless the > task is pinned in a blocked state. AFAICT the way > btree_trans::locking_wait::task is used is here is racy, and there's no > guarantee that the unwindee is actually blocked.
Occasionally returning garbage is completely fine, as long as the interface is otherwise safe. This is debug info; it's important that it be available and we can't impose additional synchronization for it.
