On Tue, Jun 16, 2026 at 04:59:53PM +0200, Christian Brauner wrote: > On Tue, Jun 16, 2026 at 02:34:43PM +0200, Christoph Hellwig wrote: > > On Tue, Jun 02, 2026 at 12:10:08PM +0200, Christian Brauner wrote: > > > fs_holder_ops recovers the owning superblock from bdev->bd_holder, which > > > forces the holder to be exactly one superblock and prevents several > > > superblocks from sharing one block device. That's what erofs is doing. > > > > > > Introduce a global dev_t-keyed rhltable mapping each block device to the > > > superblock(s) using it. The holder argument becomes purely the block > > > layer's exclusivity token (a superblock, or a file_system_type for > > > shared devices) and is no longer needed by the fs specific callbacks. > > > > Err, no. block devices need to have a specific owner. If erofs wants > > to share a device between superblock it needs to come up with an entity > > that owns the block devices which is not a superblock. > > It already did. > > > IMHO sharing devices between superblocks is a bad idea, but that ship > > has sailed, but please keep it contained inside of erofs. > > We need a simple device number to superblock mapping anyway and that can > simply be centralized in the vfs. And it can work with anon device > numbers and block device numbers uniformly.
Plus, after we're done we then also have a centry place where we can intercept what devices can be mounted by a filesystem uniformly. My first approach for this was of course to just add fs_file_open_by_*() wrappers and move the relevant security hook into there. But while doing this - ignoring the ton of bugs I found - I realized that having a mapping so we can go from device number to superblock is very helpful. We could of course keep the mapping just local to erofs but I see no reason why the vfs cannot just provide this ability natively given that it has all the required machinery. I'll let Jan chime in as well.
