All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Mike Galbraith <efault@gmx.de>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-rt-users@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: v5.14-rc3-rt1 losing wakeups?
Date: Mon, 02 Aug 2021 11:12:12 +0200	[thread overview]
Message-ID: <87k0l42osz.ffs@tglx> (raw)
In-Reply-To: <ed1d5f9ec17a5b8d758c234562dad47cfc872ed8.camel@gmx.de>

Mike,

On Sun, Aug 01 2021 at 17:14, Mike Galbraith wrote:

> On Sun, 2021-08-01 at 05:36 +0200, Mike Galbraith wrote:
>> On Fri, 2021-07-30 at 22:49 +0200, Thomas Gleixner wrote:
>> > >
>> > > First symptom is KDE/Plasma's task manager going comatose.  Notice soon
>> >
>> > KDE/Plasma points at the new fangled rtmutex based ww_mutex from
>> > Peter.
>>
>> Seems not.  When booting KVM box with nomodeset, there's exactly one
>> early boot ww_mutex lock/unlock, ancient history at the failure point.
>
> As you've probably already surmised given it isn't the ww_mutex bits,
> it's the wake_q bits.  Apply the below, 5.14-rt ceases to fail.  Take
> perfectly healthy 5.13-rt, apply those bits, and it instantly begins
> failing as 5.14-rt had been.

now staring at it makes it pretty obvious. When I picked up Peter's
patch I thought about it briefly and then ignored my doubts :(

>  /* RT mutex specific wake_q wrappers */
> -static __always_inline void rt_mutex_wake_q_add(struct rt_wake_q_head *wqh,
> +static __always_inline void rt_mutex_wake_q_add(struct rt_mutex_wake_q_head *wqh,
>  						struct rt_mutex_waiter *w)
>  {
>  	if (IS_ENABLED(CONFIG_PREEMPT_RT) && w->wake_state != TASK_NORMAL) {
> -		wake_q_add(&wqh->rt_head, w->task);
> +		get_task_struct(w->task);
> +		wqh->rtlock_task = w->task;

This is the key. With the original asymmetric version the wake_q_add for
wake_state != TASK_NORMAL is storing the task unconditionally in
wqh->rtlock_task.

With that wake_q_add() we end up with the following situation:

Some code, e.g. futex does:

     wake_q_add(..., task)

which links task->wake_q->next is !NULL. Ergo the wake_q_add() in the
rtmutex code bails out. Same the other way round if the rtmutex side
queues first then the second - regular wakeup - will not be queued.

There's two ways to fix that:

  1) Go back to my original version

  2) Add another wake_q head to task_struct

#2 is overkill IMO simply because the rtlock wait is not subject to
multiple wakeups.

Thanks a lot Mike for tracking this down!

Thanks,

        tglx

      parent reply	other threads:[~2021-08-02  9:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-30 11:07 [ANNOUNCE] v5.14-rc3-rt1 Sebastian Andrzej Siewior
2021-07-30 15:21 ` v5.14-rc3-rt1 losing wakeups? Mike Galbraith
2021-07-30 20:49   ` Thomas Gleixner
2021-07-31  1:03     ` Mike Galbraith
2021-07-31  3:33       ` Mike Galbraith
2021-07-31  8:50         ` Mike Galbraith
2021-08-01  3:36     ` Mike Galbraith
2021-08-01 15:14       ` Mike Galbraith
2021-08-02  7:02         ` Sebastian Andrzej Siewior
2021-08-02  7:18           ` Mike Galbraith
2021-08-02  8:25             ` Sebastian Andrzej Siewior
2021-08-02  8:40               ` Mike Galbraith
2021-08-02  9:12         ` Thomas Gleixner [this message]

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=87k0l42osz.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.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.