Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754481Ab2KEP10 (ORCPT ); Mon, 5 Nov 2012 10:27:26 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:42843 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754415Ab2KEP1S (ORCPT ); Mon, 5 Nov 2012 10:27:18 -0500 Date: Mon, 5 Nov 2012 13:27:07 -0200 From: Herton Ronaldo Krzesinski To: Jiri Kosina Cc: Fengguang Wu , Vivek Goyal , Ben Hutchings , Jens Axboe , LKML Subject: Re: [floppy, blk_peek_request] BUG: scheduling while atomic: kworker/u:0/6/0x10000002 Message-ID: <20121105152706.GA3200@herton-Z68MA-D2H-B3> References: <20121105070106.GA17015@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2263 Lines: 78 On Mon, Nov 05, 2012 at 02:34:13PM +0100, Jiri Kosina wrote: > On Mon, 5 Nov 2012, Jiri Kosina wrote: > > > > I got the below oops in Linux 3.7-rc4 and it's bisected down to > > > > > > commit b54e1f88897bcacc2cd359f48ea3b39eaf55f084 > > > Author: Herton Ronaldo Krzesinski > > > Date: Mon Aug 27 20:56:51 2012 -0300 > > > > > > floppy: don't call alloc_ordered_workqueue inside the alloc_disk loop > > > > Fengguang, > > > > thanks for the report. > > > > How reliable is the bisection result? (i.e. how reliably are you able to > > trigger this oops?). > > > > I am having a hard time seeing how that particular commit could be causing > > this kind of oops. > > Hmm, actually I do see an option how this might happen on machines not > having an actual floppy drive. > > Fengguang, does the patch below make any difference for you please? > > Thanks. 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. > out_put_disk: > for (drive = 0; drive < N_DRIVE; drive++) { > if (!disks[drive]) > @@ -4340,7 +4341,6 @@ out_put_disk: > } > put_disk(disks[drive]); > } > - destroy_workqueue(floppy_wq); > return err; > } > > > -- > Jiri Kosina > SUSE Labs > -- []'s Herton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/