Thread (6 messages) 6 messages, 4 authors, 2021-09-20

Re: [syzbot] WARNING in __init_work

From: "Paul E. McKenney" <paulmck@kernel.org>
Date: 2021-09-20 12:39:01
Also in: linux-fsdevel, linux-mm, lkml

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:
quoted
quoted
quoted
quoted
quoted
 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help