All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <llong@redhat.com>
Cc: mingo@redhat.com, boqun.feng@gmail.com, will@kernel.org,
	linux-kernel@vger.kernel.org, yanfei.xu@windriver.com
Subject: Re: [RFC][PATCH 3/4] locking/mutex: Introduce __mutex_trylock_or_handoff()
Date: Wed, 30 Jun 2021 20:04:34 +0200	[thread overview]
Message-ID: <YNyyMvPYBmyexlmC@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <9c47a47c-0c95-4f8f-8b62-a1aff10be748@redhat.com>

On Wed, Jun 30, 2021 at 12:30:43PM -0400, Waiman Long wrote:
> On 6/30/21 11:35 AM, Peter Zijlstra wrote:
> > Yanfei reported that it is possible to loose HANDOFF when we race with
> > mutex_unlock() and end up setting HANDOFF on an unlocked mutex. At
> > that point anybody can steal it, loosing HANDOFF in the process.
> > 
> > If this happens often enough, we can in fact starve the top waiter.
> > 
> > Solve this by folding the 'set HANDOFF' operation into the trylock
> > operation, such that either we acquire the lock, or it gets HANDOFF
> > set. This avoids having HANDOFF set on an unlocked mutex.
> > 
> > Reported-by: Yanfei Xu <yanfei.xu@windriver.com>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> >   kernel/locking/mutex.c |   58 +++++++++++++++++++++++++++++--------------------
> >   1 file changed, 35 insertions(+), 23 deletions(-)
> > 
> > --- a/kernel/locking/mutex.c
> > +++ b/kernel/locking/mutex.c
> > @@ -91,10 +91,7 @@ static inline unsigned long __owner_flag
> >   	return owner & MUTEX_FLAGS;
> >   }
> > -/*
> > - * Trylock variant that returns the owning task on failure.
> > - */
> > -static inline struct task_struct *__mutex_trylock_or_owner(struct mutex *lock)
> > +static inline struct task_struct *__mutex_trylock_common(struct mutex *lock, bool handoff)
> >   {
> >   	unsigned long owner, curr = (unsigned long)current;
> > @@ -104,39 +101,56 @@ static inline struct task_struct *__mute
> >   		unsigned long task = owner & ~MUTEX_FLAGS;
> >   		if (task) {
> > -			if (likely(task != curr))
> > +			if (flags & MUTEX_FLAG_PICKUP) {
> > +				if (task != curr)
> > +					break;
> > +				flags &= ~MUTEX_FLAG_HANDOFF;
> 
> I think you mean "flags &= ~MUTEX_FLAG_PICKUP". Right:-)

Duh, yes. That's what you get trying to write patches with a kid in your
lap.. :-)

  reply	other threads:[~2021-06-30 18:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30 15:35 [RFC][PATCH 0/4] locking/mutex: Some HANDOFF fixes Peter Zijlstra
2021-06-30 15:35 ` [RFC][PATCH 1/4] locking/mutex: Use try_cmpxchg() Peter Zijlstra
2021-07-05 11:59   ` Xu, Yanfei
2021-07-05 14:00     ` Peter Zijlstra
2021-07-05 14:52       ` Xu, Yanfei
2021-07-05 15:07       ` [PATCH] Documentation/atomic_t: Document cmpxchg() vs try_cmpxchg() Peter Zijlstra
2021-07-05 15:21         ` Will Deacon
2021-07-05 15:25         ` Xu, Yanfei
2021-07-05 17:12           ` Peter Zijlstra
2021-07-08  8:42         ` [tip: locking/core] " tip-bot2 for Peter Zijlstra
2021-07-08  8:42   ` [tip: locking/core] locking/mutex: Use try_cmpxchg() tip-bot2 for Peter Zijlstra
2021-06-30 15:35 ` [RFC][PATCH 2/4] locking/mutex: Fix HANDOFF condition Peter Zijlstra
2021-07-08  8:42   ` [tip: locking/core] " tip-bot2 for Peter Zijlstra
2021-06-30 15:35 ` [RFC][PATCH 3/4] locking/mutex: Introduce __mutex_trylock_or_handoff() Peter Zijlstra
2021-06-30 16:30   ` Waiman Long
2021-06-30 18:04     ` Peter Zijlstra [this message]
2021-07-08  8:42   ` [tip: locking/core] " tip-bot2 for Peter Zijlstra
2021-06-30 15:35 ` [RFC][PATCH 4/4] locking/mutex: Add MUTEX_WARN_ON Peter Zijlstra
2021-07-08  8:42   ` [tip: locking/core] " tip-bot2 for Peter Zijlstra
2021-06-30 19:03 ` [RFC][PATCH 0/4] locking/mutex: Some HANDOFF fixes Waiman Long
2021-07-01  2:11 ` Xu, Yanfei

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=YNyyMvPYBmyexlmC@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=boqun.feng@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llong@redhat.com \
    --cc=mingo@redhat.com \
    --cc=will@kernel.org \
    --cc=yanfei.xu@windriver.com \
    /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.