public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Chandan Babu R <chandanbabu@kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	xfs <linux-xfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	x86@kernel.org, tglx@linutronix.de
Subject: Re: Are jump labels broken on 6.11-rc1?
Date: Tue, 6 Aug 2024 11:44:13 +0200	[thread overview]
Message-ID: <20240806094413.GS37996@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20240805143522.GA623936@frogsfrogsfrogs>

On Mon, Aug 05, 2024 at 07:35:22AM -0700, Darrick J. Wong wrote:
> On Wed, Jul 31, 2024 at 12:55:57PM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 30, 2024 at 10:33:41PM -0700, Darrick J. Wong wrote:
> > 
> > > Sooooo... it turns out that somehow your patch got mismerged on the
> > > first go-round, and that worked.  The second time, there was no
> > > mismerge, which mean that the wrong atomic_cmpxchg() callsite was
> > > tested.
> > > 
> > > Looking back at the mismerge, it actually changed
> > > __static_key_slow_dec_cpuslocked, which had in 6.10:
> > > 
> > > 	if (atomic_dec_and_test(&key->enabled))
> > > 		jump_label_update(key);
> > > 
> > > Decrement, then return true if the value was set to zero.  With the 6.11
> > > code, it looks like we want to exchange a 1 with a 0, and act only if
> > > the previous value had been 1.
> > > 
> > > So perhaps we really want this change?  I'll send it out to the fleet
> > > and we'll see what it reports tomorrow morning.
> > 
> > Bah yes, I missed we had it twice. Definitely both sites want this.
> > 
> > I'll tentatively merge the below patch in tip/locking/urgent. I can
> > rebase if there is need.
> 
> Hi Peter,
> 
> This morning, I noticed the splat below with -rc2.
> 
> WARNING: CPU: 0 PID: 8578 at kernel/jump_label.c:295 __static_key_slow_dec_cpuslocked.part.0+0x50/0x60
> 
> Line 295 is the else branch of this code:
> 
> 	if (atomic_cmpxchg(&key->enabled, 1, 0) == 1)
> 		jump_label_update(key);
> 	else
> 		WARN_ON_ONCE(!static_key_slow_try_dec(key));
> 
> Apparently static_key_slow_try_dec returned false?  Looking at that
> function, I suppose the atomic_read of key->enabled returned 0, since it
> didn't trigger the "WARN_ON_ONCE(v < 0)" code.  Does that mean the value
> must have dropped from positive N to 0 without anyone ever taking the
> jump_label_mutex?

One possible scenario I see:

  slow_dec
    if (try_dec) // dec_not_one-ish, false
    // enabled == 1
				slow_inc
				  if (inc_not_disabled) // inc_not_zero-ish
				  // enabled == 2
				    return

    guard((mutex)(&jump_label_mutex);
    if (atomic_cmpxchg(1,0)==1) // false, we're 2
    
				slow_dec
				  if (try-dec) // dec_not_one, true
				  // enabled == 1
				    return
    else
      try_dec() // dec_not_one, false
      WARN


Let me go play to see how best to cure this.

> Unfortunately I'm a little too covfid-brained to figure this out today.
> :(

Urgh, brain-fog is the worst :/


  reply	other threads:[~2024-08-06  9:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-30  3:38 Are jump labels broken on 6.11-rc1? Darrick J. Wong
2024-07-30  7:30 ` Chandan Babu R
2024-07-30 13:26   ` Peter Zijlstra
2024-07-30 13:59     ` Darrick J. Wong
2024-07-31  0:19     ` Darrick J. Wong
2024-07-31  3:10       ` Darrick J. Wong
2024-07-31  5:33         ` Darrick J. Wong
2024-07-31 10:55           ` Peter Zijlstra
2024-08-05 14:35             ` Darrick J. Wong
2024-08-06  9:44               ` Peter Zijlstra [this message]
2024-08-06 10:38                 ` Peter Zijlstra
2024-08-06 22:01                   ` Darrick J. Wong
2024-08-07 14:03                   ` Thomas Gleixner
2024-08-07 14:34                     ` Peter Zijlstra
2024-08-07 14:55                       ` Thomas Gleixner
2024-08-07 15:05                         ` Darrick J. Wong
2024-08-07 22:51                           ` Darrick J. Wong
2024-08-27  3:35                           ` Darrick J. Wong
2024-09-05  8:12                             ` Peter Zijlstra
2024-09-05  9:16                               ` Peter Zijlstra
2024-09-16 16:08                                 ` Darrick J. Wong
2024-09-19 23:41                                   ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240806094413.GS37996@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=chandanbabu@kernel.org \
    --cc=djwong@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox