On Tue, Jul 30, 2024 at 05:19:50PM -0700, Darrick J. Wong wrote: > On Tue, Jul 30, 2024 at 03:26:26PM +0200, Peter Zijlstra wrote: > > On Tue, Jul 30, 2024 at 01:00:02PM +0530, Chandan Babu R wrote: > > > On Mon, Jul 29, 2024 at 08:38:49 PM -0700, Darrick J. Wong wrote: > > > > Hi everyone, > > > > > > > > I got the following splat on 6.11-rc1 when I tried to QA xfs online > > > > fsck. Does this ring a bell for anyone? I'll try bisecting in the > > > > morning to see if I can find the culprit. > > > > > > xfs/566 on v6.11-rc1 would consistently cause the oops mentioned below. > > > However, I was able to get xfs/566 to successfully execute for five times on a > > > v6.11-rc1 kernel with the following commits reverted, > > > > > > 83ab38ef0a0b2407d43af9575bb32333fdd74fb2 > > > 695ef796467ed228b60f1915995e390aea3d85c6 > > > 9bc2ff871f00437ad2f10c1eceff51aaa72b478f > > > > > > Reinstating commit 83ab38ef0a0b2407d43af9575bb32333fdd74fb2 causes the kernel > > > to oops once again. > > > > Durr, does this help? > > Yes, it does! After ~8, a full fstests run completes without incident. > > (vs. before where it would blow up within 2 minutes) > > Thanks for the fix; you can add > Tested-by: Darrick J. Wong <djwong@xxxxxxxxxx> Ofc as soon as this I push it to the whole fleet then things start failing again. :( > --D > > > > > diff --git a/kernel/jump_label.c b/kernel/jump_label.c > > index 4ad5ed8adf96..57f70dfa1f3d 100644 > > --- a/kernel/jump_label.c > > +++ b/kernel/jump_label.c > > @@ -236,7 +236,7 @@ void static_key_disable_cpuslocked(struct static_key *key) > > } > > > > jump_label_lock(); > > - if (atomic_cmpxchg(&key->enabled, 1, 0)) > > + if (atomic_cmpxchg(&key->enabled, 1, 0) == 1) > > jump_label_update(key); > > jump_label_unlock(); > > } > > >
