[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210920124557.GA18317@lst.de>
Date: Mon, 20 Sep 2021 14:45:57 +0200
From: Christoph Hellwig <hch@....de>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Dave Chinner <david@...morbit.com>,
Thomas Gleixner <tglx@...utronix.de>,
Stephen Boyd <sboyd@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
syzbot <syzbot+d6c75f383e01426a40b4@...kaller.appspotmail.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
syzkaller-bugs@...glegroups.com, Waiman Long <llong@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>,
Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [syzbot] WARNING in __init_work
On Mon, Sep 20, 2021 at 05:38:59AM -0700, Paul E. McKenney wrote:
> > 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.
In this case we really should not block here. The problem is that
we are hitting the strange bdi auto-unregister misfeature due to a bug
elsewhere. Which reminds that I have a patch series to remove this
auto unregistration which I need to bring bag once this is fixed.
That being said queue_rcu_work would have been really useful in a few
places I touched in that past.
Powered by blists - more mailing lists