The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Dmitry Ilvokhin <d@ilvokhin.com>
To: Peter Zijlstra <peterz@infradead.org>
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:37:25 +0000	[thread overview]
Message-ID: <agM7Jekhn3py3sIg@shell.ilvokhin.com> (raw)
In-Reply-To: <20260512124557.GD1889694@noisy.programming.kicks-ass.net>

On Tue, May 12, 2026 at 02:45:57PM +0200, Peter Zijlstra wrote:
> 
> What about class_irqdesc_lock_constructor() ? AFAICT
> __irq_get_desc_lock() can return NULL.

Thanks for taking a look, Peter. Yes, that is actually a very good
catch.

For some reason I naively thought __DEFINE_UNLOCK_GUARD() wouldn't be
used outside of include/linux/cleanup.h, but this is obviously wrong
assumption. There are cases, where DEFINE_LOCK_GUARD_1() doesn't fit
callers needs, so __DEFINE_UNLOCK_GUARD() is used directly.

- kernel/irq/internals.h: the case you pointed out. Can be fixed by
  moving the NULL check into the irqdesc_lock unlock expression
  directly.

- include/linux/tty_port.h: similar use case. NULL check can be moved
  into tty_port_tty as well, similar to previous case.

- kernel/sched/sched.h: lock and lock2 shouldn't be NULL at destructor
  time, since they are dereferenced unconditionally at constructor.

Below is example how this will look like. Does this look reasonable to
you, or would you prefer a different approach?

From 835d6c13caf8169db7bd049c9c549d5988fd0a82 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <d@ilvokhin.com>
Date: Tue, 12 May 2026 06:59:04 -0700
Subject: [PATCH] cleanup: Move NULL check into conditional guard unlock
 expressions

irqdesc_lock and tty_port_tty use __DEFINE_UNLOCK_GUARD() directly
with custom constructors that can set .lock to NULL. Move the NULL
check from the generic __DEFINE_UNLOCK_GUARD() destructor into their
_unlock expressions, making the NULL handling explicit at the call
site.

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
---
 include/linux/tty_port.h | 2 +-
 kernel/irq/internals.h   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/tty_port.h b/include/linux/tty_port.h
index d2a7882c0b58..cbbff6aabdad 100644
--- a/include/linux/tty_port.h
+++ b/include/linux/tty_port.h
@@ -286,7 +286,7 @@ static inline void tty_port_tty_vhangup(struct tty_port *port)
 #ifdef CONFIG_TTY
 void tty_kref_put(struct tty_struct *tty);
 __DEFINE_CLASS_IS_CONDITIONAL(tty_port_tty, true);
-__DEFINE_UNLOCK_GUARD(tty_port_tty, struct tty_struct, tty_kref_put(_T->lock));
+__DEFINE_UNLOCK_GUARD(tty_port_tty, struct tty_struct, if (_T->lock) tty_kref_put(_T->lock));
 static inline class_tty_port_tty_t class_tty_port_tty_constructor(struct tty_port *tport)
 {
 	class_tty_port_tty_t _t = {
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index 9412e57056f5..347cb333b9fe 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -171,7 +171,7 @@ void __irq_put_desc_unlock(struct irq_desc *desc, unsigned long flags, bool bus)
 
 __DEFINE_CLASS_IS_CONDITIONAL(irqdesc_lock, true);
 __DEFINE_UNLOCK_GUARD(irqdesc_lock, struct irq_desc,
-		      __irq_put_desc_unlock(_T->lock, _T->flags, _T->bus),
+		      if (_T->lock) __irq_put_desc_unlock(_T->lock, _T->flags, _T->bus),
 		      unsigned long flags; bool bus);
 
 static inline class_irqdesc_lock_t class_irqdesc_lock_constructor(unsigned int irq, bool bus,
-- 
2.53.0-Meta


  reply	other threads:[~2026-05-12 14:37 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
2026-05-12 14:37   ` Dmitry Ilvokhin [this message]
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=agM7Jekhn3py3sIg@shell.ilvokhin.com \
    --to=d@ilvokhin.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --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 \
    --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