From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Puchert, Aaron" <aaron.puchert@sap.com>,
Marco Elver <elver@google.com>,
Aaron Ballman <aaron@aaronballman.com>,
"linux-toolchains@vger.kernel.org"
<linux-toolchains@vger.kernel.org>,
"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
Bart Van Assche <bvanassche@acm.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Boqun Feng <boqun.feng@gmail.com>
Subject: Re: Thread Safety Analysis and the Linux kernel
Date: Fri, 7 Mar 2025 15:22:33 +0100 [thread overview]
Message-ID: <2025030700-research-pueblo-87ef@gregkh> (raw)
In-Reply-To: <20250307125225.GP31462@noisy.programming.kicks-ass.net>
On Fri, Mar 07, 2025 at 01:52:25PM +0100, Peter Zijlstra wrote:
> On Fri, Mar 07, 2025 at 09:52:04AM +0100, Peter Zijlstra wrote:
>
> > Yeah, so IIRC I once proposed a guard that takes a NULL pointer to mean
> > not take the lock, but people had a bit of a fit.
> >
> > It would've allowed writing the thing like:
> >
> > {
> > guard(device)(parent);
> > device_release_driver(dev);
> > }
>
> So the below does compile... Greg, how revolted are you? :-)
Eeek! But why?
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 5a1f05198114..7c95e7800b89 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -4796,33 +4796,30 @@ void device_shutdown(void)
> spin_unlock(&devices_kset->list_lock);
>
> /* hold lock to avoid race with probe/release */
> - if (parent)
> - device_lock(parent);
> - device_lock(dev);
> -
> - /* Don't allow any more runtime suspends */
> - pm_runtime_get_noresume(dev);
> - pm_runtime_barrier(dev);
> -
> - if (dev->class && dev->class->shutdown_pre) {
> - if (initcall_debug)
> - dev_info(dev, "shutdown_pre\n");
> - dev->class->shutdown_pre(dev);
> - }
> - if (dev->bus && dev->bus->shutdown) {
> - if (initcall_debug)
> - dev_info(dev, "shutdown\n");
> - dev->bus->shutdown(dev);
> - } else if (dev->driver && dev->driver->shutdown) {
> - if (initcall_debug)
> - dev_info(dev, "shutdown\n");
> - dev->driver->shutdown(dev);
> + {
> + guard(device_cond)(parent);
This is just so subtle it's scary. I don't like that.
> + guard(device)(dev);
This is fine, but really, why is this even needed? None of the code you
are indenting here breaks out of the loop early, so how/why is this even
needed?
> +
> + /* Don't allow any more runtime suspends */
> + pm_runtime_get_noresume(dev);
> + pm_runtime_barrier(dev);
> +
> + if (dev->class && dev->class->shutdown_pre) {
> + if (initcall_debug)
> + dev_info(dev, "shutdown_pre\n");
> + dev->class->shutdown_pre(dev);
> + }
> + if (dev->bus && dev->bus->shutdown) {
> + if (initcall_debug)
> + dev_info(dev, "shutdown\n");
> + dev->bus->shutdown(dev);
> + } else if (dev->driver && dev->driver->shutdown) {
> + if (initcall_debug)
> + dev_info(dev, "shutdown\n");
> + dev->driver->shutdown(dev);
> + }
> }
>
> - device_unlock(dev);
> - if (parent)
> - device_unlock(parent);
> -
So we save 3 lines? Again, feels like total overkill.
> put_device(dev);
> put_device(parent);
>
> diff --git a/include/linux/cleanup.h b/include/linux/cleanup.h
> index ec00e3f7af2b..bf72fec6f99b 100644
> --- a/include/linux/cleanup.h
> +++ b/include/linux/cleanup.h
> @@ -300,7 +300,7 @@ static __maybe_unused const bool class_##_name##_is_conditional = _is_cond
> #define DEFINE_GUARD_COND(_name, _ext, _condlock) \
> __DEFINE_CLASS_IS_CONDITIONAL(_name##_ext, true); \
> EXTEND_CLASS(_name, _ext, \
> - ({ void *_t = _T; if (_T && !(_condlock)) _t = NULL; _t; }), \
> + ({ void *_t = (_condlock) ? _T : NULL; _t; }), \
> class_##_name##_t _T) \
> static inline void * class_##_name##_ext##_lock_ptr(class_##_name##_t *_T) \
> { return class_##_name##_lock_ptr(_T); }
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 80a5b3268986..4e7ebbb7fb64 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -1046,6 +1046,7 @@ static inline void device_unlock(struct device *dev)
> }
>
> DEFINE_GUARD(device, struct device *, device_lock(_T), device_unlock(_T))
> +DEFINE_GUARD_COND(device, _cond, (_T ? (device_lock(_T), true) : false))
As I really don't want others to be calling this, worst case, just put
it in the driver core C file.
But again, ick ick ick, I worry this is going to be very subtle and
cause problems over time.
But very cool hack :)
thanks,
greg k-h
next prev parent reply other threads:[~2025-03-07 14:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 11:47 Thread Safety Analysis and the Linux kernel Marco Elver
2025-03-05 23:54 ` Puchert, Aaron
2025-03-06 9:47 ` Peter Zijlstra
2025-03-06 16:18 ` Bart Van Assche
2025-03-07 8:07 ` Peter Zijlstra
2025-03-07 21:50 ` Puchert, Aaron
2025-03-07 21:46 ` Puchert, Aaron
2025-03-06 10:08 ` Peter Zijlstra
2025-03-06 22:18 ` Puchert, Aaron
2025-03-07 7:59 ` Peter Zijlstra
2025-03-07 14:13 ` Peter Zijlstra
2025-03-06 10:37 ` Peter Zijlstra
2025-03-06 23:14 ` Puchert, Aaron
2025-03-07 8:52 ` Peter Zijlstra
2025-03-07 12:52 ` Peter Zijlstra
2025-03-07 14:22 ` Greg Kroah-Hartman [this message]
2025-03-07 14:35 ` Peter Zijlstra
2025-03-08 6:06 ` Greg Kroah-Hartman
2025-03-07 23:03 ` Puchert, Aaron
2025-03-06 17:11 ` Paul E. McKenney
2025-03-06 23:24 ` Puchert, Aaron
2025-03-06 23:44 ` Paul E. McKenney
2025-03-07 17:59 ` Puchert, Aaron
2025-03-07 18:24 ` Paul E. McKenney
2025-03-07 12:00 ` Marco Elver
2025-05-05 13:44 ` Marco Elver
2025-06-05 12:44 ` Marco Elver
2025-09-18 10:37 ` Marco Elver
2025-09-18 11:10 ` Peter Zijlstra
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=2025030700-research-pueblo-87ef@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=aaron.puchert@sap.com \
--cc=aaron@aaronballman.com \
--cc=boqun.feng@gmail.com \
--cc=bvanassche@acm.org \
--cc=elver@google.com \
--cc=linux-toolchains@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox