linux-kernel - Re: [RESEND][PATCH v18 3/8] locking/mutex: Add p->blocked

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANDhNCqRx7tpJXobHTP1uv=zf_8zarZpusA_1K9--LXm_2DXOg@mail.gmail.com>
Date: Tue, 8 Jul 2025 21:50:27 -0700
From: John Stultz <jstultz@...gle.com>
To: K Prateek Nayak <kprateek.nayak@....com>
Cc: LKML <linux-kernel@...r.kernel.org>, 
	Valentin Schneider <valentin.schneider@....com>, Joel Fernandes <joelagnelf@...dia.com>, 
	Qais Yousef <qyousef@...alina.io>, Ingo Molnar <mingo@...hat.com>, 
	Peter Zijlstra <peterz@...radead.org>, Juri Lelli <juri.lelli@...hat.com>, 
	Vincent Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>, 
	Valentin Schneider <vschneid@...hat.com>, Steven Rostedt <rostedt@...dmis.org>, 
	Ben Segall <bsegall@...gle.com>, Zimuzo Ezeozue <zezeozue@...gle.com>, Mel Gorman <mgorman@...e.de>, 
	Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>, Boqun Feng <boqun.feng@...il.com>, 
	"Paul E. McKenney" <paulmck@...nel.org>, Metin Kaya <Metin.Kaya@....com>, 
	Xuewen Yan <xuewen.yan94@...il.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Daniel Lezcano <daniel.lezcano@...aro.org>, Suleiman Souhlal <suleiman@...gle.com>, 
	kuyo chang <kuyo.chang@...iatek.com>, hupu <hupu.gm@...il.com>, kernel-team@...roid.com
Subject: Re: [RESEND][PATCH v18 3/8] locking/mutex: Add p->blocked_on wrappers
 for correctness checks

On Mon, Jul 7, 2025 at 11:44 PM K Prateek Nayak <kprateek.nayak@....com> wrote:
> On 7/8/2025 2:13 AM, John Stultz wrote:
> > @@ -2177,6 +2178,57 @@ extern int __cond_resched_rwlock_write(rwlock_t *lock);
> >       __cond_resched_rwlock_write(lock);                                      \
> >  })
> >
> > +static inline void __set_task_blocked_on(struct task_struct *p, struct mutex *m)
> > +{
> > +     WARN_ON_ONCE(!m);
> > +     /* The task should only be setting itself as blocked */
> > +     WARN_ON_ONCE(p != current);
> > +     /* Currently we serialize blocked_on under the mutex::wait_lock */
> > +     lockdep_assert_held_once(&m->wait_lock);
>
> Sorry I didn't catch this earlier but building this with PREEMPT_RT fails
> with the following error:
...
> @@ -338,12 +339,14 @@ static bool __ww_mutex_wound(struct MUTEX *lock,
>                  * wakeup pending to re-read the wounded state.
>                  */
>                 if (owner != current) {
> +#ifndef WW_RT
>                         /*
>                          * When waking up the task to wound, be sure to clear the
>                          * blocked_on pointer. Otherwise we can see circular
>                          * blocked_on relationships that can't resolve.
>                          */
>                         __clear_task_blocked_on(owner, lock);
> +#endif
>                         wake_q_add(wake_q, owner);
>                 }
>                 return true;
> ---
>
> I'll make sure to give the PREEMPT_RT build a spin next time around.
> Sorry for the oversight.

No no, thank you for letting me know! Very much appreciate the detailed testing!

Between PROXY_EXEC, SMP and PREEMPT_RT, there's a fair number of
relevant combinations to test, and I've only done so in an ad-hoc
fashion (and I'm sure I'm still missing some).
So I've added a few defconfigs along with a build script to my full
tree so I can better automate build testing across all the patches in
the series, so this hopefully doesn't bite me again.
(Though let me know if you find something else, as I probably will
need to add another defconfig to test).

I've also tried to rework your suggestion above a little more deeply
into the helper logic so we don't have as many ifdefs in the
functions.  It unfortunately touches a lot of the patch series so its
been slow going in getting all the changes in the most sensible spots.

I'll continue testing and refining the changes locally and if there's
no other feedback on the series I'll send out a v19 near the end of
the week.

thanks
-john