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

[Peter Zijlstra <peterz@infradead.org>]

On Tue, May 12, 2026 at 02:37:25PM +0000, Dmitry Ilvokhin wrote:
> 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?

Yeah, I don't mind changing things here, but like I said before, only
after a full audit of every single user ;-)

And yeah, fixing up those things shouldn't be hard, but it needs be
done.