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