From: Peter Zijlstra <peterz@infradead.org>
To: Dmitry Ilvokhin <d@ilvokhin.com>
Cc: Christian Brauner <brauner@kernel.org>,
Dan Williams <djbw@kernel.org>, Dave Jiang <dave.jiang@intel.com>,
Marco Elver <elver@google.com>, "H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH v2] cleanup: Remove NULL check from unconditional guards
Date: Tue, 12 May 2026 14:45:57 +0200 [thread overview]
Message-ID: <20260512124557.GD1889694@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260512071510.92451-1-d@ilvokhin.com>
On Tue, May 12, 2026 at 07:15:10AM +0000, Dmitry Ilvokhin wrote:
> The unconditional guard destructors check whether the lock pointer is
> NULL before unlocking. This check is dead code because unconditional
> guards guarantee a non-NULL lock pointer at destructor time.
>
> DEFINE_GUARD() and DEFINE_LOCK_GUARD_1() both run the lock operation
> in the constructor before returning. If the pointer were NULL, the
> lock operation (e.g. mutex_lock(NULL)) would crash before the
> constructor returns. The destructor never runs with a NULL pointer.
>
> DEFINE_LOCK_GUARD_0() hardcodes .lock = (void *)1 in the constructor,
> so it is never NULL by construction.
>
> Conditional (_try) variants: DEFINE_GUARD_COND() and
> DEFINE_LOCK_GUARD_1_COND() use EXTEND_CLASS_COND(), whose wrapper
> destructor returns early when the lock was not acquired, before reaching
> the base destructor since 2deccd5c862a ("cleanup: Optimize guards"):
>
> if (_cond) return; class_##_name##_destructor(_T);
>
> As compiled by GCC-11 with defconfig on top of the locking/core:
>
> Total: Before=23889980, After=23833993, chg -0.23%
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> ---
> Changes in v2:
>
> - Expand commit message with detailed reasoning, why the proposed
> change is correct.
> - Rebase on top of locking/core.
>
> v1: https://lore.kernel.org/all/20260427165037.205337-1-d@ilvokhin.com/
>
> See also [1] for relevant discussion.
>
> [1]: https://lore.kernel.org/all/afCS4d4YccQFtvpi@shell.ilvokhin.com/
>
> include/linux/cleanup.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/cleanup.h b/include/linux/cleanup.h
> index ea95ca4bc11c..1410effa8780 100644
> --- a/include/linux/cleanup.h
> +++ b/include/linux/cleanup.h
> @@ -397,7 +397,7 @@ static __maybe_unused const bool class_##_name##_is_conditional = _is_cond
> __DEFINE_GUARD_LOCK_PTR(_name, _T)
>
> #define DEFINE_GUARD(_name, _type, _lock, _unlock) \
> - DEFINE_CLASS(_name, _type, if (_T) { _unlock; }, ({ _lock; _T; }), _type _T); \
> + DEFINE_CLASS(_name, _type, _unlock, ({ _lock; _T; }), _type _T); \
> DEFINE_CLASS_IS_GUARD(_name)
>
> #define DEFINE_GUARD_COND_4(_name, _ext, _lock, _cond) \
> @@ -491,7 +491,7 @@ typedef struct { \
> static __always_inline void class_##_name##_destructor(class_##_name##_t *_T) \
> __no_context_analysis \
> { \
> - if (_T->lock) { _unlock; } \
> + _unlock; \
> } \
> \
> __DEFINE_GUARD_LOCK_PTR(_name, &_T->lock)
What about class_irqdesc_lock_constructor() ? AFAICT
__irq_get_desc_lock() can return NULL.
next prev parent reply other threads:[~2026-05-12 12:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 7:15 [PATCH v2] cleanup: Remove NULL check from unconditional guards Dmitry Ilvokhin
2026-05-12 12:45 ` Peter Zijlstra [this message]
2026-05-12 14:37 ` Dmitry Ilvokhin
2026-05-12 16:55 ` 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=20260512124557.GD1889694@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=d@ilvokhin.com \
--cc=dave.jiang@intel.com \
--cc=djbw@kernel.org \
--cc=elver@google.com \
--cc=hpa@zytor.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.