All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: mingo@redhat.com, will@kernel.org, boqun@kernel.org,
	longman@redhat.com, rostedt@goodmis.org, mhiramat@kernel.org,
	mark.rutland@arm.com, mathieu.desnoyers@efficios.com,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] locking: add mutex_lock_nospin()
Date: Wed, 4 Mar 2026 11:11:11 +0100	[thread overview]
Message-ID: <20260304101111.GQ606826@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CALOAHbC1AHc2eZrzafz7ynrW7NFPrVmervCY_jjWsRTo0gBwQQ@mail.gmail.com>

On Wed, Mar 04, 2026 at 05:37:31PM +0800, Yafang Shao wrote:
> On Wed, Mar 4, 2026 at 5:03 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Wed, Mar 04, 2026 at 03:46:49PM +0800, Yafang Shao wrote:
> > > Introduce mutex_lock_nospin(), a helper that disables optimistic spinning
> > > on the owner for specific heavy locks. This prevents long spinning times
> > > that can lead to latency spikes for other tasks on the same runqueue.
> >
> > This makes no sense; spinning stops on need_resched().
> 
> Hello Peter,
> 
> The condition to stop spinning on need_resched() relies on the mutex
> owner remaining unchanged. However, when multiple tasks contend for
> the same lock, the owner can change frequently. This creates a
> potential TOCTOU (Time of Check to Time of Use) issue.
> 
>   mutex_optimistic_spin
>       owner = __mutex_trylock_or_owner(lock);
>       mutex_spin_on_owner
>           // the __mutex_owner(lock) might get a new owner.
>           while (__mutex_owner(lock) == owner)
> 

How do these new owners become the owner? Are they succeeding the
__mutex_trylock() that sits before mutex_optimistic_spin() and
effectively starving the spinner?

Something like the below would make a difference if that were so.

---
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index c867f6c15530..0796e77a8c3b 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -521,7 +521,7 @@ static __always_inline bool
 mutex_optimistic_spin(struct mutex *lock, struct ww_acquire_ctx *ww_ctx,
 		      struct mutex_waiter *waiter)
 {
-	return false;
+	return __mutex_trylock(lock);
 }
 #endif
 
@@ -614,8 +614,7 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
 	mutex_acquire_nest(&lock->dep_map, subclass, 0, nest_lock, ip);
 
 	trace_contention_begin(lock, LCB_F_MUTEX | LCB_F_SPIN);
-	if (__mutex_trylock(lock) ||
-	    mutex_optimistic_spin(lock, ww_ctx, NULL)) {
+	if (mutex_optimistic_spin(lock, ww_ctx, NULL)) {
 		/* got the lock, yay! */
 		lock_acquired(&lock->dep_map, ip);
 		if (ww_ctx)


  reply	other threads:[~2026-03-04 10:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-04  7:46 [RFC PATCH 0/2] disable optimistic spinning for ftrace_lock Yafang Shao
2026-03-04  7:46 ` [RFC PATCH 1/2] locking: add mutex_lock_nospin() Yafang Shao
2026-03-04  9:02   ` Peter Zijlstra
2026-03-04  9:37     ` Yafang Shao
2026-03-04 10:11       ` Peter Zijlstra [this message]
2026-03-04 11:52         ` Yafang Shao
2026-03-04 12:41           ` Peter Zijlstra
2026-03-04 14:25             ` Yafang Shao
2026-03-04  9:54     ` David Laight
2026-03-04 20:57       ` Steven Rostedt
2026-03-04 21:44         ` David Laight
2026-03-05  2:17           ` Yafang Shao
2026-03-05  2:28             ` Steven Rostedt
2026-03-05  2:33               ` Yafang Shao
2026-03-05  3:00                 ` Steven Rostedt
2026-03-05  3:08                   ` Yafang Shao
2026-03-05  4:30                     ` Waiman Long
2026-03-05  5:40                       ` Yafang Shao
2026-03-05 13:21                         ` Steven Rostedt
2026-03-06  2:22                           ` Yafang Shao
2026-03-06 10:00                             ` David Laight
2026-03-09  2:34                               ` Yafang Shao
2026-03-05 18:34                         ` Waiman Long
2026-03-05 18:44                           ` Waiman Long
2026-03-06  2:27                             ` Yafang Shao
2026-03-05  9:32                       ` David Laight
2026-03-05 19:00                         ` Waiman Long
2026-03-06  2:33                           ` Yafang Shao
2026-03-06 18:12   ` kernel test robot
2026-03-06 18:24   ` kernel test robot
2026-03-04  7:46 ` [RFC PATCH 2/2] ftrace: disable optimistic spinning for ftrace_lock Yafang Shao

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=20260304101111.GQ606826@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=boqun@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.