linux-kernel - Re: [PATCH v16 3/7] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CANDhNCoj++FfLJLXAkPiROZFAj6EkvwHT7LrFK+r=oR5jmjzMQ@mail.gmail.com>
Date: Wed, 16 Apr 2025 15:44:39 -0700
From: John Stultz <jstultz@...gle.com>
To: Juri Lelli <juri.lelli@...hat.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>, 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>, K Prateek Nayak <kprateek.nayak@....com>, 
	Thomas Gleixner <tglx@...utronix.de>, Daniel Lezcano <daniel.lezcano@...aro.org>, 
	Suleiman Souhlal <suleiman@...gle.com>, kernel-team@...roid.com, 
	"Connor O'Brien" <connoro@...gle.com>
Subject: Re: [PATCH v16 3/7] locking/mutex: Add p->blocked_on wrappers for
 correctness checks

On Mon, Apr 14, 2025 at 2:09 AM Juri Lelli <juri.lelli@...hat.com> wrote:
> On 11/04/25 23:02, John Stultz wrote:
> > From: Valentin Schneider <valentin.schneider@....com>
> >
> > This lets us assert mutex::wait_lock is held whenever we access
> > p->blocked_on, as well as warn us for unexpected state changes.
> >
>
> ...
>
> > +static inline struct mutex *__get_task_blocked_on(struct task_struct *p)
> > +{
> > +     return READ_ONCE(p->blocked_on);
> > +}
> > +
>
> Shouldn't we check that wait_lock is held also when reading blocked_on?

Yeah, later in the series when I switch to the task->blocked lock we do:
https://github.com/johnstultz-work/linux-dev/blob/proxy-exec-v16-6.15-rc1/include/linux/sched.h#L2267

I think the difficulty here is just we don't have the mutex pointer in
this context to assert lock->wait_lock is held.

I guess we could assume blocked_on is the right mutex and assert that
we hold that one if it is non-null.  I'll take a shot at that.

> And, if that's the case, why do we use READ_ONCE?

So, I was thinking this was because we pulled blocked_on in some
contexts without holding the lock and we wanted to avoid the compiler
rearranging things, but it's not used that way now, so I'll drop this.

Thanks for pointing this out!
-john