Messages in this thread | | | Date | Mon, 5 Nov 2012 17:53:42 +0100 (CET) | From | Jiri Kosina <> | Subject | Re: [floppy, blk_peek_request] BUG: scheduling while atomic: kworker/u:0/6/0x10000002 |
| |
On Mon, 5 Nov 2012, Vivek Goyal wrote:
> > > Yes, I saw the same thing here, destroy_workqueue should be done before > > > clearing the queue (blk_cleanup_queue) indeed. user_reset_fdc called > > > process_fd_request and that scheduled redo_fd_request, that tries to > > > take the queue already cleaned up in set_next_request I expect. > > > > > > > > > > > > > > > > > > > > > > > drivers/block/floppy.c | 2 +- > > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > > > diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c > > > > index 1c49d71..3b9cc0f 100644 > > > > --- a/drivers/block/floppy.c > > > > +++ b/drivers/block/floppy.c > > > > @@ -4329,6 +4329,7 @@ out_unreg_region: > > > > platform_driver_unregister(&floppy_driver); > > > > out_unreg_blkdev: > > > > unregister_blkdev(FLOPPY_MAJOR, "fd"); > > > > + destroy_workqueue(floppy_wq); > > > > > > This should go right after the out_put_disk label, otherwise we may > > > leak the floppy_wq on early error. > > > > Indeed. > > > > Fengguang, could you please test with the patch below instead? (it should > > be functionally equivalent in most of the cases though). > > > > What about floppy_module_exit(). There also we seem to cleanup the queue > first before flushing and destroying floppy_wq workqueue.
Yup, will fix that up in a final patch once we have confirmation from Fengguang that it fixes the problem he is seeing.
Thanks,
-- Jiri Kosina SUSE Labs
| |