Re: [PATCH v2] cleanup: Remove NULL check from unconditional guards

[Dmitry Ilvokhin]

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?