On Thu, Dec 30, 2021 at 07:52:34PM +0900, Tetsuo Handa wrote: > > Instead of having to deal with sometimes present workqueues, why > > not move the workqueue allocation to loop_add? > > A bit of worrisome thing is that destroy_workqueue() can be called with > major_names_lock held, for loop_add() may be called as probe function from > blk_request_module(). Some unexpected dependency might bite us in future. > > We can avoid destroy_workqueue() from loop_add() if we call alloc_workqueue() > after add_disk() succeeded. But in that case calling alloc_workqueue() from > loop_configure() (which is called without global locks like major_names_lock) > sounds safer. Ok. > OK. Two patches shown below. Are these look reasonable? They do look reasonable to me based on a quick glance, but please post them one patch per mail in a separate thread for proper review.