Re: [RFC v4 linux-next 19/19] fs & block: remove bdev->bd_inode

[Al Viro <viro@zeniv.linux.org.uk>]

On Fri, Mar 22, 2024 at 03:09:30PM +0800, Yu Kuai wrote:

> > End result:
> > 
> > * old ->i_private leaked (already grabbed by your get_bdev_file())
> > * ->bd_openers at 1 (after your bdev_open() gets through)
> > * ->i_private left NULL.
> > 
> Yes, I got you now. The problem is this patch is that:
> 
> 1) opener 1, set bdev_file, bd_openers is 1
> 2) opener 2, before bdev_open(), get bdev_file,
> 3) close 1, bd_openers is 0, clear bdev_file
> 4) opener 2, after bdev_open(), bdev_file is cleared unexpected.
> 
> > Christoph, could we please get rid of that atomic_t nonsense?
> > It only confuses people into brainos like that.  It really
> > needs ->open_mutex for any kind of atomicity.
> 
> While we're here, which way should we move forward?
> 1. keep the behavior to use bdev for iomap/buffer_head for raw block
> ops;
> 2. record new 'bdev_file' in 'bd_inode->i_private', and use a new way
> to handle the concurrent scenario.
> 3. other possible solution?

OK, what lifetime rules do you intend for your objects?  It's really
hard to tell from that patch (and the last one in the main series).