Re: question about bd_inode hashing against device_add() // Re: [PATCH 03/11] block: call bdev_add later in device_add_disk

[Gao Xiang]

On 2025/10/31 17:45, Christoph Hellwig wrote:
> On Fri, Oct 31, 2025 at 05:36:45PM +0800, Gao Xiang wrote:
> > Right, sorry yes, disk_uevent(KOBJ_ADD) is in the end.
> >
> > >   Do you see that earlier, or do you have
> > > code busy polling for a node?
> >
> > Personally I think it will break many userspace programs
> > (although I also don't think it's a correct expectation.)
>
> We've had this behavior for a few years, and this is the first report
> I've seen.
>
> > After recheck internally, the userspace program logic is:
> >    - stat /dev/vdX;
> >    - if exists, mount directly;
> >    - if non-exists, listen uevent disk_add instead.
> >
> > Previously, for devtmpfs blkdev files, such stat/mount
> > assumption is always valid.
>
> That assumption doesn't seem wrong.

;-) I was thought UNIX mknod doesn't imply the device is
ready or valid in any case (but dev files in devtmpfs
might be an exception but I didn't find some formal words)...
so uevent is clearly a right way, but..

> But why does the device node
> get created earlier?  My assumption was that it would only be
> created by the KOBJ_ADD uevent.  Adding the device model maintainers
> as my little dig through the core drivers/base/ code doesn't find
> anything to the contrary, but maybe I don't fully understand it.

AFAIK, device_add() is used to trigger devtmpfs file
creation, and it can be observed if frequently
hotpluging device in the VM and mount.  Currently
I don't have time slot to build an easy reproducer,
but I think it's a real issue anyway.

Thanks,
Gao Xiang