On Mon, Sep 20, 2021 at 02:28:46PM +0200, Christoph Hellwig wrote:
> On Mon, Sep 20, 2021 at 02:03:36PM +1000, Dave Chinner wrote:
> > > >> > bdi_remove_from_list mm/backing-dev.c:938 [inline]
> > > >> > bdi_unregister+0x177/0x5a0 mm/backing-dev.c:946
> > > >> > release_bdi+0xa1/0xc0 mm/backing-dev.c:968
> > > >> > kref_put include/linux/kref.h:65 [inline]
> > > >> > bdi_put+0x72/0xa0 mm/backing-dev.c:976
> > > >> > bdev_free_inode+0x116/0x220 fs/block_dev.c:819
> > > >> > i_callback+0x3f/0x70 fs/inode.c:224
> > >
> > > The inode code uses RCU for freeing an inode object which then ends up
> > > calling bdi_put() and subsequently in synchronize_rcu_expedited().
> >
> > Commit 889c05cc5834 ("block: ensure the bdi is freed after
> > inode_detach_wb") might be a good place to start looking here. It
> > moved the release of the bdi from ->evict context to the RCU freeing
> > of the blockdev inode...
>
> Well, the block code already does a bdi_unregister in del_gendisk.
> So if we end up freeing the whole device bdev with a registered bdi
> something is badly going wrong. Unfortunately the log in this report
> isn't much help on how we got there. IIRC syzbot will eventually spew
> out a reproducer, so it might be worth to wait for that.
If it does turn out that you need to block in an RCU callback,
queue_rcu_work() can be helpful. This schedules a workqueue from the RCU
callback, allowing the function passed to the preceding INIT_RCU_WORK()
to block.
Thanx, Paul
