Re: WARNING in block layer triggered in 3.17-rc3

2014-09-09 Thread Tejun Heo
Hello, Alan. On Tue, Sep 09, 2014 at 11:08:22AM -0400, Alan Stern wrote: > Sorry, the meaning wasn't clear. I meant that the existing code > doesn't work. The patch seems to work okay (except that I can't use > queue_flag_test_and_set because the queue isn't locked at that point). > I'll sub

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-09 Thread Alan Stern
On Tue, 9 Sep 2014, Tejun Heo wrote: > Hello, > > On Mon, Sep 08, 2014 at 01:42:44PM -0400, Alan Stern wrote: > > > This looks like a nasty hack. In theory the QUEUE_FLAG_INIT_DONE should > > > be unset on blk_unregister_queue() to match the teardown; it's only > > > accident it isn't. del_gend

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread Tejun Heo
Hello, On Mon, Sep 08, 2014 at 01:42:44PM -0400, Alan Stern wrote: > > This looks like a nasty hack. In theory the QUEUE_FLAG_INIT_DONE should > > be unset on blk_unregister_queue() to match the teardown; it's only > > accident it isn't. del_gendisk() in sd_remove() is supposed to tear a > > lot

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread Alan Stern
On Mon, 8 Sep 2014, James Bottomley wrote: > > Jens and James, it appears the problem is in blk_register_queue(). The > > code does this: > > > > /* > > * Initialization must be complete by now. Finish the initial > > * bypass from queue allocation. > > */ > > queue_flag

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread Shirish Pargaonkar
see this issue/warning in 3.12 also. On Mon, Sep 8, 2014 at 10:51 AM, James Bottomley wrote: > On Mon, 2014-09-08 at 10:51 -0400, Alan Stern wrote: >> On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: >> >> > I think the problem is, when a gendisk is detached, its request queue >> > is not put in byp

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread James Bottomley
On Mon, 2014-09-08 at 10:51 -0400, Alan Stern wrote: > On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: > > > I think the problem is, when a gendisk is detached, its request queue > > is not put in bypass mode > > cause when it is re-attached, code tries to put it out of bypass mode, > > hence the wa

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread Shirish Pargaonkar
So should a request queue be in bypass mode when the device is being detached and queue is being unregistereed because requests can get queued up? On Mon, Sep 8, 2014 at 9:51 AM, Alan Stern wrote: > On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: > >> I think the problem is, when a gendisk is deta

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread Alan Stern
On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: > I think the problem is, when a gendisk is detached, its request queue > is not put in bypass mode > cause when it is re-attached, code tries to put it out of bypass mode, > hence the warning. > > So either of these should work, I have not tested it,

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-07 Thread Shirish Pargaonkar
I think the problem is, when a gendisk is detached, its request queue is not put in bypass mode cause when it is re-attached, code tries to put it out of bypass mode, hence the warning. So either of these should work, I have not tested it, just coded it up. diff --git a/block/blk-sysfs.c b/block/

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-07 Thread Ming Lei
On Sat, Sep 6, 2014 at 1:45 AM, Alan Stern wrote: > James and Jens: > > I got a WARNING when unbinding the sd driver from a USB flash drive and > then binding it back again. Here's where the flash drive gets probed > initially: > > [ 143.300886] usb-storage 4-8:1.0: usb_probe_interface > [ 143.

WARNING in block layer triggered in 3.17-rc3

2014-09-05 Thread Alan Stern
James and Jens: I got a WARNING when unbinding the sd driver from a USB flash drive and then binding it back again. Here's where the flash drive gets probed initially: [ 143.300886] usb-storage 4-8:1.0: usb_probe_interface [ 143.300911] usb-storage 4-8:1.0: usb_probe_interface - got id [ 143