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.
