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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
