Re: [PATCH V2] driver core: auxiliary bus: Fix sysfs creation on bind

[Leon Romanovsky <leon@kernel.org>]

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:
> > 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.
> 
> > 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