On Fri, Feb 20, 2026 at 12:14:12PM +0100, Danilo Krummrich wrote:

On Fri Feb 20, 2026 at 9:04 AM CET, Leon Romanovsky wrote:

quoted

This init->add->remove->destroy pattern follows standard Linux kernel practice.
I expect all current review tools to flag any missing function call
among these three.

I'm not saying that the flow is not logical, goes against existing patterns,
etc., I'm saying that it is unnecessary to expose a new API to drivers, since
this is already handled internally.

I.e. we can easily fix the bug without increasing the API surface exposing a new
API to drivers.

quoted

It is not, atomic is not a replacement for locking and this hunk is
going to be racy as hell:

No, of course not, but it is sufficient to ensure that something runs only once.

No, atomic doesn't ensure that. Atomic makes sure that write/read
variable isn't "interrupted" in the middle.

Multiple simultaneous calls to auxiliary_irq_dir_prepare() without lock can return
that sysfs.irq_dir_exists isn't set yet, will try to call to devm_device_add_group()
which will fail.

However, you are still right, since sysfs_create_group() can still fail, we
still need the mutex, because we may need to unwind.

If you decide to keep lock, you won't need atomic_t for irq_dir_exists.

Thanks