Re: [PATCH] bsg: convert to use blk-mq
On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: > Requires a few changes to the FC transport class as well. > > Cc: Johannes Thumshirn > Cc: Benjamin Block > Cc: linux-scsi@vger.kernel.org > Signed-off-by: Jens Axboe > --- > block/bsg-lib.c | 102 +-- > drivers/scsi/scsi_transport_fc.c | 61 ++ > 2 files changed, 91 insertions(+), 72 deletions(-) > Hey Jens, I haven't had time to look into this in any deep way - but I did plan to -, but just to see whether it starts and runs some I/O I tried giving it a spin and came up with nothing (see line 3 and 5): [ 14.082079] scsi host0: scsi_eh_0: sleeping [ 14.082288] scsi host0: zfcp [ 14.086823] scsi host0: fc_host0: bsg interface failed to initialize - setup queue [ 14.089198] qdio: 0.0.1900 ZFCP on SC 107 using AI:1 QEBSM:0 PRI:1 TDD:1 SIGA: W AP [ 15.228583] rport-0:0-0: failed to setup bsg queue [ 15.229886] scsi 0:0:0:0: scsi scan: INQUIRY pass 1 length 36 [ 15.230801] scsi 0:0:0:0: scsi scan: INQUIRY successful with code 0x0 [ 15.230860] scsi 0:0:0:0: scsi scan: INQUIRY pass 2 length 164 [ 15.231171] scsi 0:0:0:0: scsi scan: INQUIRY successful with code 0x0 [ 15.231190] scsi 0:0:0:0: scsi scan: peripheral device type of 31, no device added [ 15.233171] scsi 0:0:0:0: scsi scan: Sending REPORT LUNS to (try 0) [ 15.234144] scsi 0:0:0:0: scsi scan: REPORT LUNS successful (try 0) result 0x0 [ 15.234156] scsi 0:0:0:0: scsi scan: REPORT LUN scan [ 15.235040] scsi 0:0:0:1082671104: scsi scan: INQUIRY pass 1 length 36 [ 15.235220] scsi host1: scsi_eh_1: sleeping [ 15.235336] scsi 0:0:0:1082671104: scsi scan: INQUIRY successful with code 0x0 [ 15.235355] scsi 0:0:0:1082671104: scsi scan: INQUIRY pass 2 length 164 [ 15.235434] scsi host1: zfcp [ 15.235667] scsi 0:0:0:1082671104: scsi scan: INQUIRY successful with code 0x0 [ 15.235709] scsi 0:0:0:1082671104: Direct-Access IBM 2107900 3230 PQ: 0 ANSI: 5 [ 15.238468] scsi host1: fc_host1: bsg interface failed to initialize - setup queue Seems to already fail at setting up the bsg interfaces for zFCP - at loading time of the module. This is just your patch on top of 4.19.0-rc8. -- With Best Regards, Benjamin Block / Linux on IBM Z Kernel Development IBM Systems & Technology Group / IBM Deutschland Research & Development GmbH Vorsitz. AufsR.: Martina Koederitz / Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294
Re: [PATCH] bsg: convert to use blk-mq
On 10/17/18 9:55 AM, Benjamin Block wrote: > On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: >> Requires a few changes to the FC transport class as well. >> >> Cc: Johannes Thumshirn >> Cc: Benjamin Block >> Cc: linux-scsi@vger.kernel.org >> Signed-off-by: Jens Axboe >> --- >> block/bsg-lib.c | 102 +-- >> drivers/scsi/scsi_transport_fc.c | 61 ++ >> 2 files changed, 91 insertions(+), 72 deletions(-) >> > > Hey Jens, > > I haven't had time to look into this in any deep way - but I did plan to > -, but just to see whether it starts and runs some I/O I tried giving it > a spin and came up with nothing (see line 3 and 5): I'm an idiot, can you try this on top? diff --git a/block/bsg-lib.c b/block/bsg-lib.c index 1aa0ed3fc339..95e12b635225 100644 --- a/block/bsg-lib.c +++ b/block/bsg-lib.c @@ -311,7 +311,7 @@ struct request_queue *bsg_setup_queue(struct device *dev, const char *name, int ret = -ENOMEM; set = kzalloc(sizeof(*set), GFP_KERNEL); - if (set) + if (!set) return ERR_PTR(-ENOMEM); set->ops = &bsg_mq_ops; -- Jens Axboe
Re: [PATCH] bsg: convert to use blk-mq
On 2018-10-17 11:55 a.m., Benjamin Block wrote: On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: Requires a few changes to the FC transport class as well. Cc: Johannes Thumshirn Cc: Benjamin Block Cc: linux-scsi@vger.kernel.org Signed-off-by: Jens Axboe --- block/bsg-lib.c | 102 +-- drivers/scsi/scsi_transport_fc.c | 61 ++ 2 files changed, 91 insertions(+), 72 deletions(-) Hey Jens, I haven't had time to look into this in any deep way - but I did plan to -, but just to see whether it starts and runs some I/O I tried giving it a spin and came up with nothing (see line 3 and 5): [ 14.082079] scsi host0: scsi_eh_0: sleeping [ 14.082288] scsi host0: zfcp [ 14.086823] scsi host0: fc_host0: bsg interface failed to initialize - setup queue [ 14.089198] qdio: 0.0.1900 ZFCP on SC 107 using AI:1 QEBSM:0 PRI:1 TDD:1 SIGA: W AP [ 15.228583] rport-0:0-0: failed to setup bsg queue [ 15.229886] scsi 0:0:0:0: scsi scan: INQUIRY pass 1 length 36 [ 15.230801] scsi 0:0:0:0: scsi scan: INQUIRY successful with code 0x0 [ 15.230860] scsi 0:0:0:0: scsi scan: INQUIRY pass 2 length 164 [ 15.231171] scsi 0:0:0:0: scsi scan: INQUIRY successful with code 0x0 [ 15.231190] scsi 0:0:0:0: scsi scan: peripheral device type of 31, no device added [ 15.233171] scsi 0:0:0:0: scsi scan: Sending REPORT LUNS to (try 0) [ 15.234144] scsi 0:0:0:0: scsi scan: REPORT LUNS successful (try 0) result 0x0 [ 15.234156] scsi 0:0:0:0: scsi scan: REPORT LUN scan [ 15.235040] scsi 0:0:0:1082671104: scsi scan: INQUIRY pass 1 length 36 [ 15.235220] scsi host1: scsi_eh_1: sleeping [ 15.235336] scsi 0:0:0:1082671104: scsi scan: INQUIRY successful with code 0x0 [ 15.235355] scsi 0:0:0:1082671104: scsi scan: INQUIRY pass 2 length 164 [ 15.235434] scsi host1: zfcp [ 15.235667] scsi 0:0:0:1082671104: scsi scan: INQUIRY successful with code 0x0 [ 15.235709] scsi 0:0:0:1082671104: Direct-Access IBM 2107900 3230 PQ: 0 ANSI: 5 [ 15.238468] scsi host1: fc_host1: bsg interface failed to initialize - setup queue Seems to already fail at setting up the bsg interfaces for zFCP - at loading time of the module. This is just your patch on top of 4.19.0-rc8. Hi, Almost all of the utilities in the sg3_utils package (a few exceptions: sg_reset, sgm_dd, sgp_dd), when given a bsg file node (e.g. 'sg_inq /dev/bsg/0:0:0:1'), will use the bsg sg_v4 interface (i.e. as defined in ). Dito with the sdparm and ddpt packages. So there is a lot of test code for any changes to the bsg driver. Doug Gilbert P.S. that above is true from sg3_utils version 1.27 released on 20090411. The current version is 1.44
Re: [PATCH] bsg: convert to use blk-mq
On 10/17/18 12:08 PM, Douglas Gilbert wrote: > On 2018-10-17 11:55 a.m., Benjamin Block wrote: >> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: >>> Requires a few changes to the FC transport class as well. >>> >>> Cc: Johannes Thumshirn >>> Cc: Benjamin Block >>> Cc: linux-scsi@vger.kernel.org >>> Signed-off-by: Jens Axboe >>> --- >>> block/bsg-lib.c | 102 +-- >>> drivers/scsi/scsi_transport_fc.c | 61 ++ >>> 2 files changed, 91 insertions(+), 72 deletions(-) >>> >> >> Hey Jens, >> >> I haven't had time to look into this in any deep way - but I did plan to >> -, but just to see whether it starts and runs some I/O I tried giving it >> a spin and came up with nothing (see line 3 and 5): >> >> [ 14.082079] scsi host0: scsi_eh_0: sleeping >> [ 14.082288] scsi host0: zfcp >> [ 14.086823] scsi host0: fc_host0: bsg interface failed to initialize - >> setup queue >> [ 14.089198] qdio: 0.0.1900 ZFCP on SC 107 using AI:1 QEBSM:0 PRI:1 TDD:1 >> SIGA: W AP >> [ 15.228583] rport-0:0-0: failed to setup bsg queue >> [ 15.229886] scsi 0:0:0:0: scsi scan: INQUIRY pass 1 length 36 >> [ 15.230801] scsi 0:0:0:0: scsi scan: INQUIRY successful with code 0x0 >> [ 15.230860] scsi 0:0:0:0: scsi scan: INQUIRY pass 2 length 164 >> [ 15.231171] scsi 0:0:0:0: scsi scan: INQUIRY successful with code 0x0 >> [ 15.231190] scsi 0:0:0:0: scsi scan: peripheral device type of 31, no >> device added >> [ 15.233171] scsi 0:0:0:0: scsi scan: Sending REPORT LUNS to (try 0) >> [ 15.234144] scsi 0:0:0:0: scsi scan: REPORT LUNS successful (try 0) >> result 0x0 >> [ 15.234156] scsi 0:0:0:0: scsi scan: REPORT LUN scan >> [ 15.235040] scsi 0:0:0:1082671104: scsi scan: INQUIRY pass 1 length 36 >> [ 15.235220] scsi host1: scsi_eh_1: sleeping >> [ 15.235336] scsi 0:0:0:1082671104: scsi scan: INQUIRY successful with >> code 0x0 >> [ 15.235355] scsi 0:0:0:1082671104: scsi scan: INQUIRY pass 2 length 164 >> [ 15.235434] scsi host1: zfcp >> [ 15.235667] scsi 0:0:0:1082671104: scsi scan: INQUIRY successful with >> code 0x0 >> [ 15.235709] scsi 0:0:0:1082671104: Direct-Access IBM 2107900 >> 3230 PQ: 0 ANSI: 5 >> [ 15.238468] scsi host1: fc_host1: bsg interface failed to initialize - >> setup queue >> >> >> Seems to already fail at setting up the bsg interfaces for zFCP - at >> loading time of the module. This is just your patch on top of >> 4.19.0-rc8. > > Hi, > Almost all of the utilities in the sg3_utils package (a few exceptions: > sg_reset, sgm_dd, sgp_dd), when given a bsg file node (e.g. > 'sg_inq /dev/bsg/0:0:0:1'), will use the bsg sg_v4 interface (i.e. as > defined in ). Dito with the sdparm and ddpt packages. > So there is a lot of test code for any changes to the bsg driver. That's good info, I did in fact run test tools on the bsg nodes and verified that it worked fine. But I could not test the embedded queues like Benjamin is doing above - and those were broken due to a silly wrong pointer check. So hopefully with that fixed, it'll work just fine. -- Jens Axboe
Re: [PATCH] bsg: convert to use blk-mq
On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: > On 10/17/18 9:55 AM, Benjamin Block wrote: > > On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: > >> Requires a few changes to the FC transport class as well. > >> > >> Cc: Johannes Thumshirn > >> Cc: Benjamin Block > >> Cc: linux-scsi@vger.kernel.org > >> Signed-off-by: Jens Axboe > >> --- > >> block/bsg-lib.c | 102 +-- > >> drivers/scsi/scsi_transport_fc.c | 61 ++ > >> 2 files changed, 91 insertions(+), 72 deletions(-) > >> > > > > Hey Jens, > > > > I haven't had time to look into this in any deep way - but I did plan to > > -, but just to see whether it starts and runs some I/O I tried giving it > > a spin and came up with nothing (see line 3 and 5): > > I'm an idiot, can you try this on top? > > > diff --git a/block/bsg-lib.c b/block/bsg-lib.c > index 1aa0ed3fc339..95e12b635225 100644 > --- a/block/bsg-lib.c > +++ b/block/bsg-lib.c > @@ -311,7 +311,7 @@ struct request_queue *bsg_setup_queue(struct device *dev, > const char *name, > int ret = -ENOMEM; > > set = kzalloc(sizeof(*set), GFP_KERNEL); > - if (set) > + if (!set) > return ERR_PTR(-ENOMEM); > > set->ops = &bsg_mq_ops; > Well, yes, that would be wrong. But it still doesn't fly (s390x stack trace): [ 36.271953] scsi host0: scsi_eh_0: sleeping [ 36.272571] scsi host0: zfcp [ 36.298065] WARNING: CPU: 7 PID: 856 at block/blk-settings.c:71 blk_queue_rq_timed_out+0x44/0x60 [ 36.298315] Modules linked in: zfcp scsi_transport_fc dm_multipath [ 36.299015] CPU: 7 PID: 856 Comm: systemd-udevd Tainted: GW 4.19.0-rc8-bb-next+ #1 [ 36.299059] Hardware name: IBM 3906 M03 704 (LPAR) [ 36.299101] Krnl PSW : 0704e0018000 00ced494 (blk_queue_rq_timed_out+0x44/0x60) [ 36.299192]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 [ 36.299259] Krnl GPRS: 015cee60 a0ce0180 0300 [ 36.299304]0300 00ced486 a5738000 03ff8069eba0 [ 36.299349]a11ec6a8 a0ce a11ec400 03ff805ee438 [ 36.299394]a0ce 03ff805f6b00 00ced486 a28af0b0 [ 36.299460] Krnl Code: 00ced486: e310c182ltg %r1,384(%r12) 00ced48c: a7840004brc 8,ced494 #00ced490: a7f40001brc 15,ced492 >00ced494: 4120c150la %r2,336(%r12) 00ced498: c0e5ffc76290brasl %r14,5d99b8 00ced49e: e3b0c1500024stg %r11,336(%r12) 00ced4a4: ebbff0a4lmg %r11,%r15,160(%r15) 00ced4aa: 07febcr 15,%r14 [ 36.299879] Call Trace: [ 36.299922] ([] 0xa11ec6a8) [ 36.299979] [<03ff805ee3fa>] fc_host_setup+0x622/0x660 [scsi_transport_fc] [ 36.300029] [<00f0baca>] transport_setup_classdev+0x62/0x70 [ 36.300075] [<00f0b592>] attribute_container_add_device+0x182/0x1d0 [ 36.300163] [<03ff80503cae>] scsi_sysfs_add_host+0x5e/0x100 [scsi_mod] [ 36.300245] [<03ff804e6d7c>] scsi_add_host_with_dma+0x2dc/0x468 [scsi_mod] [ 36.300310] [<03ff806835f2>] zfcp_scsi_adapter_register+0x222/0x260 [zfcp] [ 36.300373] [<03ff8066a49a>] zfcp_adapter_enqueue+0xae2/0xb20 [zfcp] [ 36.300435] [<03ff8066b436>] zfcp_ccw_set_online+0xb6/0x208 [zfcp] [ 36.300482] [<00f8ad14>] ccw_device_set_online+0x41c/0x878 [ 36.300527] [<00f8b374>] online_store_recog_and_online+0x204/0x230 [ 36.300572] [<00f8de20>] online_store+0x290/0x3e8 [ 36.300619] [<007842c0>] kernfs_fop_write+0x1b0/0x288 [ 36.300663] [<0064217e>] __vfs_write+0xee/0x398 [ 36.300705] [<006426b4>] vfs_write+0xec/0x238 [ 36.300754] [<00642abe>] ksys_write+0xd6/0x148 [ 36.300800] [<0137b668>] system_call+0x2b0/0x2d0 [ 36.300843] 5 locks held by systemd-udevd/856: [ 36.300882] #0: da3c74e2 (sb_writers#4){.+.+}, at: vfs_write+0xd6/0x238 [ 36.301053] #1: 2a1f461f (&of->mutex){+.+.}, at: kernfs_fop_write+0x258/0x288 [ 36.301202] #2: deb28615 (kn->count#52){.+.+}, at: kernfs_fop_write+0x26e/0x288 [ 36.301374] #3: 2ddb9663 (&dev->mutex){}, at: online_store+0x19c/0x3e8 [ 36.301523] #4: 982b5ed9 (attribute_container_mutex){+.+.}, at: attribute_container_add_device+0x3c/0x1d0 [ 36.301675] Last Breaking-Event-Address: [ 36.301717] [<00ced490>] blk_queue_rq_timed_out+0x40/0x60 [ 36.301758] irq event stamp: 9073 [ 36.301804] hardirqs last enabled at (9081):
Re: [PATCH] bsg: convert to use blk-mq
On 10/19/18 9:01 AM, Benjamin Block wrote: > On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: >> On 10/17/18 9:55 AM, Benjamin Block wrote: >>> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: Requires a few changes to the FC transport class as well. Cc: Johannes Thumshirn Cc: Benjamin Block Cc: linux-scsi@vger.kernel.org Signed-off-by: Jens Axboe --- block/bsg-lib.c | 102 +-- drivers/scsi/scsi_transport_fc.c | 61 ++ 2 files changed, 91 insertions(+), 72 deletions(-) >>> >>> Hey Jens, >>> >>> I haven't had time to look into this in any deep way - but I did plan to >>> -, but just to see whether it starts and runs some I/O I tried giving it >>> a spin and came up with nothing (see line 3 and 5): >> >> I'm an idiot, can you try this on top? >> >> >> diff --git a/block/bsg-lib.c b/block/bsg-lib.c >> index 1aa0ed3fc339..95e12b635225 100644 >> --- a/block/bsg-lib.c >> +++ b/block/bsg-lib.c >> @@ -311,7 +311,7 @@ struct request_queue *bsg_setup_queue(struct device >> *dev, const char *name, >> int ret = -ENOMEM; >> >> set = kzalloc(sizeof(*set), GFP_KERNEL); >> -if (set) >> +if (!set) >> return ERR_PTR(-ENOMEM); >> >> set->ops = &bsg_mq_ops; >> > > Well, yes, that would be wrong. But it still doesn't fly (s390x stack > trace): > > [ 36.271953] scsi host0: scsi_eh_0: sleeping > [ 36.272571] scsi host0: zfcp > [ 36.298065] WARNING: CPU: 7 PID: 856 at block/blk-settings.c:71 > blk_queue_rq_timed_out+0x44/0x60 > [ 36.298315] Modules linked in: zfcp scsi_transport_fc dm_multipath > [ 36.299015] CPU: 7 PID: 856 Comm: systemd-udevd Tainted: GW > 4.19.0-rc8-bb-next+ #1 > [ 36.299059] Hardware name: IBM 3906 M03 704 (LPAR) > [ 36.299101] Krnl PSW : 0704e0018000 00ced494 > (blk_queue_rq_timed_out+0x44/0x60) > [ 36.299192]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 > RI:0 EA:3 > [ 36.299259] Krnl GPRS: 015cee60 a0ce0180 > 0300 > [ 36.299304]0300 00ced486 a5738000 > 03ff8069eba0 > [ 36.299349]a11ec6a8 a0ce a11ec400 > 03ff805ee438 > [ 36.299394]a0ce 03ff805f6b00 00ced486 > a28af0b0 > [ 36.299460] Krnl Code: 00ced486: e310c182ltg > %r1,384(%r12) > 00ced48c: a7840004brc > 8,ced494 > #00ced490: a7f40001brc > 15,ced492 > >00ced494: 4120c150la > %r2,336(%r12) > 00ced498: c0e5ffc76290brasl > %r14,5d99b8 > 00ced49e: e3b0c1500024stg > %r11,336(%r12) > 00ced4a4: ebbff0a4lmg > %r11,%r15,160(%r15) > 00ced4aa: 07febcr > 15,%r14 > [ 36.299879] Call Trace: > [ 36.299922] ([] 0xa11ec6a8) > [ 36.299979] [<03ff805ee3fa>] fc_host_setup+0x622/0x660 > [scsi_transport_fc] > [ 36.300029] [<00f0baca>] transport_setup_classdev+0x62/0x70 > [ 36.300075] [<00f0b592>] > attribute_container_add_device+0x182/0x1d0 > [ 36.300163] [<03ff80503cae>] scsi_sysfs_add_host+0x5e/0x100 > [scsi_mod] > [ 36.300245] [<03ff804e6d7c>] scsi_add_host_with_dma+0x2dc/0x468 > [scsi_mod] > [ 36.300310] [<03ff806835f2>] zfcp_scsi_adapter_register+0x222/0x260 > [zfcp] > [ 36.300373] [<03ff8066a49a>] zfcp_adapter_enqueue+0xae2/0xb20 [zfcp] > [ 36.300435] [<03ff8066b436>] zfcp_ccw_set_online+0xb6/0x208 [zfcp] > [ 36.300482] [<00f8ad14>] ccw_device_set_online+0x41c/0x878 > [ 36.300527] [<00f8b374>] > online_store_recog_and_online+0x204/0x230 > [ 36.300572] [<00f8de20>] online_store+0x290/0x3e8 > [ 36.300619] [<007842c0>] kernfs_fop_write+0x1b0/0x288 > [ 36.300663] [<0064217e>] __vfs_write+0xee/0x398 > [ 36.300705] [<006426b4>] vfs_write+0xec/0x238 > [ 36.300754] [<00642abe>] ksys_write+0xd6/0x148 > [ 36.300800] [<0137b668>] system_call+0x2b0/0x2d0 > [ 36.300843] 5 locks held by systemd-udevd/856: > [ 36.300882] #0: da3c74e2 (sb_writers#4){.+.+}, at: > vfs_write+0xd6/0x238 > [ 36.301053] #1: 2a1f461f (&of->mutex){+.+.}, at: > kernfs_fop_write+0x258/0x288 > [ 36.301202] #2: deb28615 (kn->count#52){.+.+}, at: > kernfs_fop_write+0x26e/0x288 > [ 36.301374] #3: 2ddb9663 (&dev->mutex){}, at: > online_store+0x19c/0x3e8 > [ 36.301523] #4: 982b5ed9 (attribute_container_mutex){+.+.}, at: > attribute_container_add_device+0x3
Re: [PATCH] bsg: convert to use blk-mq
On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: > On 10/19/18 9:01 AM, Benjamin Block wrote: > > On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: > >> On 10/17/18 9:55 AM, Benjamin Block wrote: > >>> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: > Requires a few changes to the FC transport class as well. > > Cc: Johannes Thumshirn > Cc: Benjamin Block > Cc: linux-scsi@vger.kernel.org > Signed-off-by: Jens Axboe > --- > block/bsg-lib.c | 102 +-- > drivers/scsi/scsi_transport_fc.c | 61 ++ > 2 files changed, 91 insertions(+), 72 deletions(-) > > >>> > >>> Hey Jens, > >>> > >>> I haven't had time to look into this in any deep way - but I did plan to > >>> -, but just to see whether it starts and runs some I/O I tried giving it > >>> a spin and came up with nothing (see line 3 and 5): > >> > >> I'm an idiot, can you try this on top? > >> > >> > >> diff --git a/block/bsg-lib.c b/block/bsg-lib.c > >> index 1aa0ed3fc339..95e12b635225 100644 > >> --- a/block/bsg-lib.c > >> +++ b/block/bsg-lib.c > >> @@ -311,7 +311,7 @@ struct request_queue *bsg_setup_queue(struct device > >> *dev, const char *name, > >>int ret = -ENOMEM; > >> > >>set = kzalloc(sizeof(*set), GFP_KERNEL); > >> - if (set) > >> + if (!set) > >>return ERR_PTR(-ENOMEM); > >> > >>set->ops = &bsg_mq_ops; > >> > > > > Well, yes, that would be wrong. But it still doesn't fly (s390x stack > > trace): > > > > [ 36.271953] scsi host0: scsi_eh_0: sleeping > > [ 36.272571] scsi host0: zfcp > > [ 36.298065] WARNING: CPU: 7 PID: 856 at block/blk-settings.c:71 > > blk_queue_rq_timed_out+0x44/0x60 > > [ 36.298315] Modules linked in: zfcp scsi_transport_fc dm_multipath > > [ 36.299015] CPU: 7 PID: 856 Comm: systemd-udevd Tainted: GW > >4.19.0-rc8-bb-next+ #1 > > [ 36.299059] Hardware name: IBM 3906 M03 704 (LPAR) > > [ 36.299101] Krnl PSW : 0704e0018000 00ced494 > > (blk_queue_rq_timed_out+0x44/0x60) > > [ 36.299192]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 > > PM:0 RI:0 EA:3 > > [ 36.299259] Krnl GPRS: 015cee60 > > a0ce0180 0300 > > [ 36.299304]0300 00ced486 > > a5738000 03ff8069eba0 > > [ 36.299349]a11ec6a8 a0ce > > a11ec400 03ff805ee438 > > [ 36.299394]a0ce 03ff805f6b00 > > 00ced486 a28af0b0 > > [ 36.299460] Krnl Code: 00ced486: e310c182ltg > > %r1,384(%r12) > > 00ced48c: a7840004brc > > 8,ced494 > > #00ced490: a7f40001brc > > 15,ced492 > > >00ced494: 4120c150la > > %r2,336(%r12) > > 00ced498: c0e5ffc76290brasl > > %r14,5d99b8 > > 00ced49e: e3b0c1500024stg > > %r11,336(%r12) > > 00ced4a4: ebbff0a4lmg > > %r11,%r15,160(%r15) > > 00ced4aa: 07febcr > > 15,%r14 > > [ 36.299879] Call Trace: > > [ 36.299922] ([] 0xa11ec6a8) > > [ 36.299979] [<03ff805ee3fa>] fc_host_setup+0x622/0x660 > > [scsi_transport_fc] > > [ 36.300029] [<00f0baca>] transport_setup_classdev+0x62/0x70 > > [ 36.300075] [<00f0b592>] > > attribute_container_add_device+0x182/0x1d0 > > [ 36.300163] [<03ff80503cae>] scsi_sysfs_add_host+0x5e/0x100 > > [scsi_mod] > > [ 36.300245] [<03ff804e6d7c>] scsi_add_host_with_dma+0x2dc/0x468 > > [scsi_mod] > > [ 36.300310] [<03ff806835f2>] zfcp_scsi_adapter_register+0x222/0x260 > > [zfcp] > > [ 36.300373] [<03ff8066a49a>] zfcp_adapter_enqueue+0xae2/0xb20 > > [zfcp] > > [ 36.300435] [<03ff8066b436>] zfcp_ccw_set_online+0xb6/0x208 [zfcp] > > [ 36.300482] [<00f8ad14>] ccw_device_set_online+0x41c/0x878 > > [ 36.300527] [<00f8b374>] > > online_store_recog_and_online+0x204/0x230 > > [ 36.300572] [<00f8de20>] online_store+0x290/0x3e8 > > [ 36.300619] [<007842c0>] kernfs_fop_write+0x1b0/0x288 > > [ 36.300663] [<0064217e>] __vfs_write+0xee/0x398 > > [ 36.300705] [<006426b4>] vfs_write+0xec/0x238 > > [ 36.300754] [<00642abe>] ksys_write+0xd6/0x148 > > [ 36.300800] [<0137b668>] system_call+0x2b0/0x2d0 > > [ 36.300843] 5 locks held by systemd-udevd/856: > > [ 36.300882] #0: da3c74e2 (sb_writers#4){.+.+}, at: > > vfs_write+0xd6/0x238 > > [ 36.301053] #1: 2a1f461f (&of->mutex){+.+.}, at: > > kernfs_fop_write+0x258/0x288 > > [ 36.301202] #2: d
Re: [PATCH] bsg: convert to use blk-mq
On 10/19/18 9:57 AM, Benjamin Block wrote: > On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: >> On 10/19/18 9:01 AM, Benjamin Block wrote: >>> On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: On 10/17/18 9:55 AM, Benjamin Block wrote: > On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: >> Requires a few changes to the FC transport class as well. >> >> Cc: Johannes Thumshirn >> Cc: Benjamin Block >> Cc: linux-scsi@vger.kernel.org >> Signed-off-by: Jens Axboe >> --- >> block/bsg-lib.c | 102 +-- >> drivers/scsi/scsi_transport_fc.c | 61 ++ >> 2 files changed, 91 insertions(+), 72 deletions(-) >> > > Hey Jens, > > I haven't had time to look into this in any deep way - but I did plan to > -, but just to see whether it starts and runs some I/O I tried giving it > a spin and came up with nothing (see line 3 and 5): I'm an idiot, can you try this on top? diff --git a/block/bsg-lib.c b/block/bsg-lib.c index 1aa0ed3fc339..95e12b635225 100644 --- a/block/bsg-lib.c +++ b/block/bsg-lib.c @@ -311,7 +311,7 @@ struct request_queue *bsg_setup_queue(struct device *dev, const char *name, int ret = -ENOMEM; set = kzalloc(sizeof(*set), GFP_KERNEL); - if (set) + if (!set) return ERR_PTR(-ENOMEM); set->ops = &bsg_mq_ops; >>> >>> Well, yes, that would be wrong. But it still doesn't fly (s390x stack >>> trace): >>> >>> [ 36.271953] scsi host0: scsi_eh_0: sleeping >>> [ 36.272571] scsi host0: zfcp >>> [ 36.298065] WARNING: CPU: 7 PID: 856 at block/blk-settings.c:71 >>> blk_queue_rq_timed_out+0x44/0x60 >>> [ 36.298315] Modules linked in: zfcp scsi_transport_fc dm_multipath >>> [ 36.299015] CPU: 7 PID: 856 Comm: systemd-udevd Tainted: GW >>>4.19.0-rc8-bb-next+ #1 >>> [ 36.299059] Hardware name: IBM 3906 M03 704 (LPAR) >>> [ 36.299101] Krnl PSW : 0704e0018000 00ced494 >>> (blk_queue_rq_timed_out+0x44/0x60) >>> [ 36.299192]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 >>> PM:0 RI:0 EA:3 >>> [ 36.299259] Krnl GPRS: 015cee60 >>> a0ce0180 0300 >>> [ 36.299304]0300 00ced486 >>> a5738000 03ff8069eba0 >>> [ 36.299349]a11ec6a8 a0ce >>> a11ec400 03ff805ee438 >>> [ 36.299394]a0ce 03ff805f6b00 >>> 00ced486 a28af0b0 >>> [ 36.299460] Krnl Code: 00ced486: e310c182ltg >>> %r1,384(%r12) >>> 00ced48c: a7840004brc >>> 8,ced494 >>> #00ced490: a7f40001brc >>> 15,ced492 >>> >00ced494: 4120c150la >>> %r2,336(%r12) >>> 00ced498: c0e5ffc76290brasl >>> %r14,5d99b8 >>> 00ced49e: e3b0c1500024stg >>> %r11,336(%r12) >>> 00ced4a4: ebbff0a4lmg >>> %r11,%r15,160(%r15) >>> 00ced4aa: 07febcr >>> 15,%r14 >>> [ 36.299879] Call Trace: >>> [ 36.299922] ([] 0xa11ec6a8) >>> [ 36.299979] [<03ff805ee3fa>] fc_host_setup+0x622/0x660 >>> [scsi_transport_fc] >>> [ 36.300029] [<00f0baca>] transport_setup_classdev+0x62/0x70 >>> [ 36.300075] [<00f0b592>] >>> attribute_container_add_device+0x182/0x1d0 >>> [ 36.300163] [<03ff80503cae>] scsi_sysfs_add_host+0x5e/0x100 >>> [scsi_mod] >>> [ 36.300245] [<03ff804e6d7c>] scsi_add_host_with_dma+0x2dc/0x468 >>> [scsi_mod] >>> [ 36.300310] [<03ff806835f2>] zfcp_scsi_adapter_register+0x222/0x260 >>> [zfcp] >>> [ 36.300373] [<03ff8066a49a>] zfcp_adapter_enqueue+0xae2/0xb20 >>> [zfcp] >>> [ 36.300435] [<03ff8066b436>] zfcp_ccw_set_online+0xb6/0x208 [zfcp] >>> [ 36.300482] [<00f8ad14>] ccw_device_set_online+0x41c/0x878 >>> [ 36.300527] [<00f8b374>] >>> online_store_recog_and_online+0x204/0x230 >>> [ 36.300572] [<00f8de20>] online_store+0x290/0x3e8 >>> [ 36.300619] [<007842c0>] kernfs_fop_write+0x1b0/0x288 >>> [ 36.300663] [<0064217e>] __vfs_write+0xee/0x398 >>> [ 36.300705] [<006426b4>] vfs_write+0xec/0x238 >>> [ 36.300754] [<00642abe>] ksys_write+0xd6/0x148 >>> [ 36.300800] [<0137b668>] system_call+0x2b0/0x2d0 >>> [ 36.300843] 5 locks held by systemd-udevd/856: >>> [ 36.300882] #0: da3c74e2 (sb_writers#4){.+.+}, at: >>> vfs_write+0xd6/0x238 >>> [ 36.301053] #1: 2a1f461f (&of->mutex){+.+.}, at: >>> kernfs_fop_write+0
Re: [PATCH] bsg: convert to use blk-mq
On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: > On 10/19/18 9:01 AM, Benjamin Block wrote: > > On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: > >> On 10/17/18 9:55 AM, Benjamin Block wrote: > >>> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: > Requires a few changes to the FC transport class as well. > > Cc: Johannes Thumshirn > Cc: Benjamin Block > Cc: linux-scsi@vger.kernel.org > Signed-off-by: Jens Axboe > --- > block/bsg-lib.c | 102 +-- > drivers/scsi/scsi_transport_fc.c | 61 ++ > 2 files changed, 91 insertions(+), 72 deletions(-) > > > but that's not going to apply cleanly... Can you just try and run my > mq-conversions branch? That has everything, and it also has that > alloc failure fixed. > > git://git.kernel.dk/linux-block mq-conversions > Ok so, that gets past the stage where we initialize the queues. Simple SCSI-I/O also seems to work, that is for example an INQUIRY(10), but transport commands that get passed to the driver break. Tried to send a FibreChannel GPN_FT (remote port discovery). As the BSG interface goes. This is a bidirectional command, that has both a buffer for the request and for the reply. AFAIR BSG will create a struct request for each of them. Protocol is BSG_PROTOCOL_SCSI, Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be transparent till we get into the driver. First got this: [ 566.531100] BUG: sleeping function called from invalid context at mm/slab.h:421 [ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name: bsg_api_test [ 566.531460] 1 lock held by bsg_api_test/3104: [ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at: hctx_lock+0x30/0x118 [ 566.531498] Preemption disabled at: [ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218 [ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW 4.19.0-rc6-bb-next+ #1 [ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR) [ 566.531533] Call Trace: [ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8) [ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8 [ 566.531565] [<00196410>] ___might_sleep+0x280/0x298 [ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560 [ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0 [ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118 [ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670 [ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130 [ 566.531615] [<00820dfe>] blk_mq_sched_dispatch_requests+0x156/0x1a0 [ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160 [ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218 [ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0 [ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8 [ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80 [ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8 [ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500 [ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710 [ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0 [ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40 [ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0 [ 566.531815] 1 lock held by bsg_api_test/3104: [ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at: hctx_lock+0x30/0x118 And then it dies completely: [ 566.531854] Unable to handle kernel pointer dereference in virtual kernel address space [ 566.531861] Failing address: TEID: 0483 [ 566.531867] Fault in home space mode while using kernel ASCE. [ 566.531885] AS:013ec007 R3:effc8007 S:effce000 P:013d [ 566.531927] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 566.531938] Modules linked in: ... [ 566.532042] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW 4.19.0-rc6-bb-next+ #1 [ 566.532047] Hardware name: IBM 3906 M03 704 (LPAR) [ 566.532051] Krnl PSW : d16c67b2 e4a74b5c (zfcp_fc_exec_bsg_job+0x116/0x2c0 [zfcp]) [ 566.532071]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 566.532077] Krnl GPRS: 1000 bfb84178 0001 8004 [ 566.532082]1000 a6625108 0001 [ 566.532086]bfb870e8 b6276930 bb3a6fc8 [ 566.532091]b6276800 03ff80306228 03ff802fc048 a7313830 [ 566.532104] Krnl Code: 03ff802fc090: a7740004brc 7,3ff802fc098 [ 566.532104]03ff802fc094: a7f4002ebrc 15,3ff802fc0f0 [ 566.532104] #03ff802fc098: e310a034lg %r1,48(%r10)
Re: [PATCH] bsg: convert to use blk-mq
On 10/22/18 4:03 AM, Benjamin Block wrote: > On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: >> On 10/19/18 9:01 AM, Benjamin Block wrote: >>> On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: On 10/17/18 9:55 AM, Benjamin Block wrote: > On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: >> Requires a few changes to the FC transport class as well. >> >> Cc: Johannes Thumshirn >> Cc: Benjamin Block >> Cc: linux-scsi@vger.kernel.org >> Signed-off-by: Jens Axboe >> --- >> block/bsg-lib.c | 102 +-- >> drivers/scsi/scsi_transport_fc.c | 61 ++ >> 2 files changed, 91 insertions(+), 72 deletions(-) >> >> >> but that's not going to apply cleanly... Can you just try and run my >> mq-conversions branch? That has everything, and it also has that >> alloc failure fixed. >> >> git://git.kernel.dk/linux-block mq-conversions >> > > Ok so, that gets past the stage where we initialize the queues. Simple > SCSI-I/O also seems to work, that is for example an INQUIRY(10), but > transport commands that get passed to the driver break. Tried to send > a FibreChannel GPN_FT (remote port discovery). > > As the BSG interface goes. This is a bidirectional command, that has > both a buffer for the request and for the reply. AFAIR BSG will create a > struct request for each of them. Protocol is BSG_PROTOCOL_SCSI, > Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be > transparent till we get into the driver. > > First got this: > > [ 566.531100] BUG: sleeping function called from invalid context at > mm/slab.h:421 > [ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name: > bsg_api_test > [ 566.531460] 1 lock held by bsg_api_test/3104: > [ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at: > hctx_lock+0x30/0x118 > [ 566.531498] Preemption disabled at: > [ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218 > [ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW > 4.19.0-rc6-bb-next+ #1 > [ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR) > [ 566.531533] Call Trace: > [ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8) > [ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8 > [ 566.531565] [<00196410>] ___might_sleep+0x280/0x298 > [ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560 > [ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0 > [ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118 > [ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670 > [ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130 > [ 566.531615] [<00820dfe>] > blk_mq_sched_dispatch_requests+0x156/0x1a0 > [ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160 > [ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218 > [ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0 > [ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8 > [ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80 > [ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8 > [ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500 > [ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710 > [ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0 > [ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40 > [ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0 > [ 566.531815] 1 lock held by bsg_api_test/3104: > [ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at: > hctx_lock+0x30/0x118 > > And then it dies completely: > > [ 566.531854] Unable to handle kernel pointer dereference in virtual kernel > address space > [ 566.531861] Failing address: TEID: 0483 > [ 566.531867] Fault in home space mode while using kernel ASCE. > [ 566.531885] AS:013ec007 R3:effc8007 S:effce000 > P:013d > [ 566.531927] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 566.531938] Modules linked in: ... > [ 566.532042] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW > 4.19.0-rc6-bb-next+ #1 > [ 566.532047] Hardware name: IBM 3906 M03 704 (LPAR) > [ 566.532051] Krnl PSW : d16c67b2 e4a74b5c > (zfcp_fc_exec_bsg_job+0x116/0x2c0 [zfcp]) > [ 566.532071]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 > RI:0 EA:3 > [ 566.532077] Krnl GPRS: 1000 bfb84178 0001 > 8004 > [ 566.532082]1000 a6625108 > 0001 > [ 566.532086]bfb870e8 b6276930 > bb3a6fc8 > [ 566.532091]b6276800 03ff80306228 03ff802fc048 > a7313830 > [ 566.532104] Krnl Code: 03ff802fc090: a7740004
Re: [PATCH] bsg: convert to use blk-mq
On Mon, Oct 22, 2018 at 06:38:36AM -0600, Jens Axboe wrote: > On 10/22/18 4:03 AM, Benjamin Block wrote: > > On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: > >> On 10/19/18 9:01 AM, Benjamin Block wrote: > >>> On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: > On 10/17/18 9:55 AM, Benjamin Block wrote: > > On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: > >> Requires a few changes to the FC transport class as well. > >> > >> Cc: Johannes Thumshirn > >> Cc: Benjamin Block > >> Cc: linux-scsi@vger.kernel.org > >> Signed-off-by: Jens Axboe > >> --- > >> block/bsg-lib.c | 102 +-- > >> drivers/scsi/scsi_transport_fc.c | 61 ++ > >> 2 files changed, 91 insertions(+), 72 deletions(-) > >> > >> > >> but that's not going to apply cleanly... Can you just try and run my > >> mq-conversions branch? That has everything, and it also has that > >> alloc failure fixed. > >> > >> git://git.kernel.dk/linux-block mq-conversions > >> > > > > Ok so, that gets past the stage where we initialize the queues. Simple > > SCSI-I/O also seems to work, that is for example an INQUIRY(10), but > > transport commands that get passed to the driver break. Tried to send > > a FibreChannel GPN_FT (remote port discovery). > > > > As the BSG interface goes. This is a bidirectional command, that has > > both a buffer for the request and for the reply. AFAIR BSG will create a > > struct request for each of them. Protocol is BSG_PROTOCOL_SCSI, > > Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be > > transparent till we get into the driver. > > > > First got this: > > > > [ 566.531100] BUG: sleeping function called from invalid context at > > mm/slab.h:421 > > [ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name: > > bsg_api_test > > [ 566.531460] 1 lock held by bsg_api_test/3104: > > [ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at: > > hctx_lock+0x30/0x118 > > [ 566.531498] Preemption disabled at: > > [ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218 > > [ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW > >4.19.0-rc6-bb-next+ #1 > > [ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR) > > [ 566.531533] Call Trace: > > [ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8) > > [ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8 > > [ 566.531565] [<00196410>] ___might_sleep+0x280/0x298 > > [ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560 > > [ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0 > > [ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118 > > [ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670 > > [ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130 > > [ 566.531615] [<00820dfe>] > > blk_mq_sched_dispatch_requests+0x156/0x1a0 > > [ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160 > > [ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218 > > [ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0 > > [ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8 > > [ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80 > > [ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8 > > [ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500 > > [ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710 > > [ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0 > > [ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40 > > [ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0 > > [ 566.531815] 1 lock held by bsg_api_test/3104: > > [ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at: > > hctx_lock+0x30/0x118 > > > > And then it dies completely: > > > > [ 566.531854] Unable to handle kernel pointer dereference in virtual > > kernel address space > > [ 566.531861] Failing address: TEID: 0483 > > [ 566.531867] Fault in home space mode while using kernel ASCE. > > [ 566.531885] AS:013ec007 R3:effc8007 S:effce000 > > P:013d > > [ 566.531927] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC > > [ 566.531938] Modules linked in: ... > > [ 566.532042] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW > >4.19.0-rc6-bb-next+ #1 > > [ 566.532047] Hardware name: IBM 3906 M03 704 (LPAR) > > [ 566.532051] Krnl PSW : d16c67b2 e4a74b5c > > (zfcp_fc_exec_bsg_job+0x116/0x2c0 [zfcp]) > > [ 566.532071]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 > > PM:0 RI:0 EA:3 > > [ 566.532077] Krnl GPRS: 1000 bfb84178 > > 0001 8004 > > [ 566.532082]1000 a6625108 > > 000
Re: [PATCH] bsg: convert to use blk-mq
On 10/22/18 9:21 AM, Benjamin Block wrote: > On Mon, Oct 22, 2018 at 06:38:36AM -0600, Jens Axboe wrote: >> On 10/22/18 4:03 AM, Benjamin Block wrote: >>> On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: On 10/19/18 9:01 AM, Benjamin Block wrote: > On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: >> On 10/17/18 9:55 AM, Benjamin Block wrote: >>> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: Requires a few changes to the FC transport class as well. Cc: Johannes Thumshirn Cc: Benjamin Block Cc: linux-scsi@vger.kernel.org Signed-off-by: Jens Axboe --- block/bsg-lib.c | 102 +-- drivers/scsi/scsi_transport_fc.c | 61 ++ 2 files changed, 91 insertions(+), 72 deletions(-) but that's not going to apply cleanly... Can you just try and run my mq-conversions branch? That has everything, and it also has that alloc failure fixed. git://git.kernel.dk/linux-block mq-conversions >>> >>> Ok so, that gets past the stage where we initialize the queues. Simple >>> SCSI-I/O also seems to work, that is for example an INQUIRY(10), but >>> transport commands that get passed to the driver break. Tried to send >>> a FibreChannel GPN_FT (remote port discovery). >>> >>> As the BSG interface goes. This is a bidirectional command, that has >>> both a buffer for the request and for the reply. AFAIR BSG will create a >>> struct request for each of them. Protocol is BSG_PROTOCOL_SCSI, >>> Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be >>> transparent till we get into the driver. >>> >>> First got this: >>> >>> [ 566.531100] BUG: sleeping function called from invalid context at >>> mm/slab.h:421 >>> [ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name: >>> bsg_api_test >>> [ 566.531460] 1 lock held by bsg_api_test/3104: >>> [ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at: >>> hctx_lock+0x30/0x118 >>> [ 566.531498] Preemption disabled at: >>> [ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218 >>> [ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW >>>4.19.0-rc6-bb-next+ #1 >>> [ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR) >>> [ 566.531533] Call Trace: >>> [ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8) >>> [ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8 >>> [ 566.531565] [<00196410>] ___might_sleep+0x280/0x298 >>> [ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560 >>> [ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0 >>> [ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118 >>> [ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670 >>> [ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130 >>> [ 566.531615] [<00820dfe>] >>> blk_mq_sched_dispatch_requests+0x156/0x1a0 >>> [ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160 >>> [ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218 >>> [ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0 >>> [ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8 >>> [ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80 >>> [ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8 >>> [ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500 >>> [ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710 >>> [ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0 >>> [ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40 >>> [ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0 >>> [ 566.531815] 1 lock held by bsg_api_test/3104: >>> [ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at: >>> hctx_lock+0x30/0x118 >>> >>> And then it dies completely: >>> >>> [ 566.531854] Unable to handle kernel pointer dereference in virtual >>> kernel address space >>> [ 566.531861] Failing address: TEID: 0483 >>> [ 566.531867] Fault in home space mode while using kernel ASCE. >>> [ 566.531885] AS:013ec007 R3:effc8007 S:effce000 >>> P:013d >>> [ 566.531927] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC >>> [ 566.531938] Modules linked in: ... >>> [ 566.532042] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW >>>4.19.0-rc6-bb-next+ #1 >>> [ 566.532047] Hardware name: IBM 3906 M03 704 (LPAR) >>> [ 566.532051] Krnl PSW : d16c67b2 e4a74b5c >>> (zfcp_fc_exec_bsg_job+0x116/0x2c0 [zfcp]) >>> [ 566.532071]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 >>> PM:0 RI:0 EA:3 >>> [ 566.532077] Krnl GPRS: 1000 bfb84178 >>> 0001 8004 >>> [ 566.532082]1000 a66251
Re: [PATCH] bsg: convert to use blk-mq
On Mon, Oct 22, 2018 at 06:38:36AM -0600, Jens Axboe wrote: > On 10/22/18 4:03 AM, Benjamin Block wrote: > > On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: > > > > Ok so, that gets past the stage where we initialize the queues. Simple > > SCSI-I/O also seems to work, that is for example an INQUIRY(10), but > > transport commands that get passed to the driver break. Tried to send > > a FibreChannel GPN_FT (remote port discovery). > > > > As the BSG interface goes. This is a bidirectional command, that has > > both a buffer for the request and for the reply. AFAIR BSG will create a > > struct request for each of them. Protocol is BSG_PROTOCOL_SCSI, > > Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be > > transparent till we get into the driver. > > > > First got this: > > > > [ 566.531100] BUG: sleeping function called from invalid context at > > mm/slab.h:421 > > [ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name: > > bsg_api_test > > [ 566.531460] 1 lock held by bsg_api_test/3104: > > [ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at: > > hctx_lock+0x30/0x118 > > [ 566.531498] Preemption disabled at: > > [ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218 > > [ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW > >4.19.0-rc6-bb-next+ #1 > > [ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR) > > [ 566.531533] Call Trace: > > [ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8) > > [ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8 > > [ 566.531565] [<00196410>] ___might_sleep+0x280/0x298 > > [ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560 > > [ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0 > > [ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118 > > [ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670 > > [ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130 > > [ 566.531615] [<00820dfe>] > > blk_mq_sched_dispatch_requests+0x156/0x1a0 > > [ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160 > > [ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218 > > [ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0 > > [ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8 > > [ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80 > > [ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8 > > [ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500 > > [ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710 > > [ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0 > > [ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40 > > [ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0 > > [ 566.531815] 1 lock held by bsg_api_test/3104: > > [ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at: > > hctx_lock+0x30/0x118 > > > > The first one is an easy fix, not sure how I missed that. The other > one I have no idea, any chance you could try with this one: > > http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=142dc9f36e3113b6a76d472978c33c8c2a2b702c > > which fixes the first one, and also corrects a wrong end_io call, > but I don't think that's the cause of the above. > > If it crashes, can you figure out where in the source that is? > Basically just do > > gdb vmlinux > l *zfcp_fc_exec_bsg_job+0x116 > > assuming that works fine on s390 :-) > So I tried 4.19.0 with only the two patches from you: http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=142dc9f36e3113b6a76d472978c33c8c2a2b702c This fixed the first warning from before, as you suggested, but it still crash like this: [ ] Unable to handle kernel pointer dereference in virtual kernel address space [ ] Failing address: TEID: 0483 [ ] Fault in home space mode while using kernel ASCE. [ ] AS:025f0007 R3:dffb8007 S:dffbf000 P:013d [ ] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ ] Modules linked in: [ ] CPU: 2 PID: 609 Comm: kworker/2:1H Kdump: loaded Tainted: GW 4.19.0-bb-next+ #1 [ ] Hardware name: IBM 3906 M03 704 (LPAR) [ ] Workqueue: kblockd blk_mq_run_work_fn [ ] Krnl PSW : 0704e0018000 03ff806a6b40 (zfcp_fc_exec_bsg_job+0x1c0/0x440 [zfcp]) [ ]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 [ ] Krnl GPRS: 83e0f3c0 0300 [ ]0300 03ff806a6b3a a86b5948 a86b5988 [ ]83e0f3f0 a86b5938 984aee80 [ ]a86b5800 03ff806ba950 03ff806a6b3a 98a5ed88 [ ] Krnl Code: 03ff806a6b
Re: [PATCH] bsg: convert to use blk-mq
On 10/23/18 11:40 AM, Benjamin Block wrote: > On Mon, Oct 22, 2018 at 06:38:36AM -0600, Jens Axboe wrote: >> On 10/22/18 4:03 AM, Benjamin Block wrote: >>> On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: >>> >>> Ok so, that gets past the stage where we initialize the queues. Simple >>> SCSI-I/O also seems to work, that is for example an INQUIRY(10), but >>> transport commands that get passed to the driver break. Tried to send >>> a FibreChannel GPN_FT (remote port discovery). >>> >>> As the BSG interface goes. This is a bidirectional command, that has >>> both a buffer for the request and for the reply. AFAIR BSG will create a >>> struct request for each of them. Protocol is BSG_PROTOCOL_SCSI, >>> Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be >>> transparent till we get into the driver. >>> >>> First got this: >>> >>> [ 566.531100] BUG: sleeping function called from invalid context at >>> mm/slab.h:421 >>> [ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name: >>> bsg_api_test >>> [ 566.531460] 1 lock held by bsg_api_test/3104: >>> [ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at: >>> hctx_lock+0x30/0x118 >>> [ 566.531498] Preemption disabled at: >>> [ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218 >>> [ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW >>>4.19.0-rc6-bb-next+ #1 >>> [ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR) >>> [ 566.531533] Call Trace: >>> [ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8) >>> [ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8 >>> [ 566.531565] [<00196410>] ___might_sleep+0x280/0x298 >>> [ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560 >>> [ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0 >>> [ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118 >>> [ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670 >>> [ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130 >>> [ 566.531615] [<00820dfe>] >>> blk_mq_sched_dispatch_requests+0x156/0x1a0 >>> [ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160 >>> [ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218 >>> [ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0 >>> [ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8 >>> [ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80 >>> [ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8 >>> [ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500 >>> [ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710 >>> [ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0 >>> [ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40 >>> [ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0 >>> [ 566.531815] 1 lock held by bsg_api_test/3104: >>> [ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at: >>> hctx_lock+0x30/0x118 >>> >> >> The first one is an easy fix, not sure how I missed that. The other >> one I have no idea, any chance you could try with this one: >> >> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=142dc9f36e3113b6a76d472978c33c8c2a2b702c >> >> which fixes the first one, and also corrects a wrong end_io call, >> but I don't think that's the cause of the above. >> >> If it crashes, can you figure out where in the source that is? >> Basically just do >> >> gdb vmlinux >> l *zfcp_fc_exec_bsg_job+0x116 >> >> assuming that works fine on s390 :-) >> > > So I tried 4.19.0 with only the two patches from you: > http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa > http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=142dc9f36e3113b6a76d472978c33c8c2a2b702c > > This fixed the first warning from before, as you suggested, but it still > crash like this: > > [ ] Unable to handle kernel pointer dereference in virtual kernel address > space > [ ] Failing address: TEID: 0483 > [ ] Fault in home space mode while using kernel ASCE. > [ ] AS:025f0007 R3:dffb8007 S:dffbf000 > P:013d > [ ] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ ] Modules linked in: > [ ] CPU: 2 PID: 609 Comm: kworker/2:1H Kdump: loaded Tainted: GW >4.19.0-bb-next+ #1 > [ ] Hardware name: IBM 3906 M03 704 (LPAR) > [ ] Workqueue: kblockd blk_mq_run_work_fn > [ ] Krnl PSW : 0704e0018000 03ff806a6b40 > (zfcp_fc_exec_bsg_job+0x1c0/0x440 [zfcp]) > [ ]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 > [ ] Krnl GPRS: 83e0f3c0 > 0300 > [ ]0300 03ff806a6b3a a86b5948 > a86b5988 > [ ]83e0f3f0 a86b5938 > 984aee80 >
Re: [PATCH] bsg: convert to use blk-mq
On Mon, Oct 22, 2018 at 03:23:30AM -0600, Jens Axboe wrote: > JFYI, I also reordered the series to make it correct. You can apply > this one: > > http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa > > before the bsg patch, and it should be fine. Or just use the above branch, > of course. Hell no on that one. The behavior of having methods right on the request_queue which can be changed any time is something we absolutely must not introduce into blk-mq. Just add pass a timeout hander to bsg_register_queue which is called from the bsg ->timeout handler is a much better way to sort our your problem. It can also easily be turned into an independent prep patch.
Re: [PATCH] bsg: convert to use blk-mq
On 10/24/18 5:19 AM, Christoph Hellwig wrote: > On Mon, Oct 22, 2018 at 03:23:30AM -0600, Jens Axboe wrote: >> JFYI, I also reordered the series to make it correct. You can apply >> this one: >> >> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa >> >> before the bsg patch, and it should be fine. Or just use the above branch, >> of course. > > Hell no on that one. The behavior of having methods right on the > request_queue which can be changed any time is something we absolutely > must not introduce into blk-mq. I agree it's not the prettiest, but it's not like it's something that is changed at runtime. > Just add pass a timeout hander to bsg_register_queue which is called > from the bsg ->timeout handler is a much better way to sort our your > problem. It can also easily be turned into an independent prep patch. Good idea, that is cleaner. -- Jens Axboe
Re: [PATCH] bsg: convert to use blk-mq
On 10/24/18 5:30 AM, Jens Axboe wrote: > On 10/24/18 5:19 AM, Christoph Hellwig wrote: >> On Mon, Oct 22, 2018 at 03:23:30AM -0600, Jens Axboe wrote: >>> JFYI, I also reordered the series to make it correct. You can apply >>> this one: >>> >>> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa >>> >>> before the bsg patch, and it should be fine. Or just use the above branch, >>> of course. >> >> Hell no on that one. The behavior of having methods right on the >> request_queue which can be changed any time is something we absolutely >> must not introduce into blk-mq. > > I agree it's not the prettiest, but it's not like it's something > that is changed at runtime. > >> Just add pass a timeout hander to bsg_register_queue which is called >> from the bsg ->timeout handler is a much better way to sort our your >> problem. It can also easily be turned into an independent prep patch. > > Good idea, that is cleaner. Except that STILL doesn't work with mq_ops being a constant, I'd have to allocate it. -- Jens Axboe
Re: [PATCH] bsg: convert to use blk-mq
On 10/24/18 5:52 AM, Jens Axboe wrote: > On 10/24/18 5:30 AM, Jens Axboe wrote: >> On 10/24/18 5:19 AM, Christoph Hellwig wrote: >>> On Mon, Oct 22, 2018 at 03:23:30AM -0600, Jens Axboe wrote: JFYI, I also reordered the series to make it correct. You can apply this one: http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa before the bsg patch, and it should be fine. Or just use the above branch, of course. >>> >>> Hell no on that one. The behavior of having methods right on the >>> request_queue which can be changed any time is something we absolutely >>> must not introduce into blk-mq. >> >> I agree it's not the prettiest, but it's not like it's something >> that is changed at runtime. >> >>> Just add pass a timeout hander to bsg_register_queue which is called >>> from the bsg ->timeout handler is a much better way to sort our your >>> problem. It can also easily be turned into an independent prep patch. >> >> Good idea, that is cleaner. > > Except that STILL doesn't work with mq_ops being a constant, I'd have > to allocate it. Which obviously won't work. I don't see a good way out of this, since I can't store the private timeout handler anywhere. Open to suggestions, but until something better comes up, I'm keeping q->timeout and removing the API to set it. bsg-lib can just manually set it in the queue. -- Jens Axboe
Re: [PATCH] bsg: convert to use blk-mq
On 10/24/18 6:02 AM, Jens Axboe wrote: > On 10/24/18 5:52 AM, Jens Axboe wrote: >> On 10/24/18 5:30 AM, Jens Axboe wrote: >>> On 10/24/18 5:19 AM, Christoph Hellwig wrote: On Mon, Oct 22, 2018 at 03:23:30AM -0600, Jens Axboe wrote: > JFYI, I also reordered the series to make it correct. You can apply > this one: > > http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa > > before the bsg patch, and it should be fine. Or just use the above branch, > of course. Hell no on that one. The behavior of having methods right on the request_queue which can be changed any time is something we absolutely must not introduce into blk-mq. >>> >>> I agree it's not the prettiest, but it's not like it's something >>> that is changed at runtime. >>> Just add pass a timeout hander to bsg_register_queue which is called from the bsg ->timeout handler is a much better way to sort our your problem. It can also easily be turned into an independent prep patch. >>> >>> Good idea, that is cleaner. >> >> Except that STILL doesn't work with mq_ops being a constant, I'd have >> to allocate it. > > Which obviously won't work. I don't see a good way out of this, since > I can't store the private timeout handler anywhere. Open to suggestions, > but until something better comes up, I'm keeping q->timeout and > removing the API to set it. bsg-lib can just manually set it in the > queue. Pushed that out - it's now ->bsg_job_timeout_fn, and nobody sets it but bsg when it initializes the queue. bsg sets up a default timeout handler, and calls ->bsg_job_timeout_fn, if defined. Not that that is any different than from before, but at least it's obvious what it's for now. -- Jens Axboe
Re: [PATCH] bsg: convert to use blk-mq
On 10/23/18 12:07 PM, Jens Axboe wrote: > On 10/23/18 11:40 AM, Benjamin Block wrote: >> On Mon, Oct 22, 2018 at 06:38:36AM -0600, Jens Axboe wrote: >>> On 10/22/18 4:03 AM, Benjamin Block wrote: On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: Ok so, that gets past the stage where we initialize the queues. Simple SCSI-I/O also seems to work, that is for example an INQUIRY(10), but transport commands that get passed to the driver break. Tried to send a FibreChannel GPN_FT (remote port discovery). As the BSG interface goes. This is a bidirectional command, that has both a buffer for the request and for the reply. AFAIR BSG will create a struct request for each of them. Protocol is BSG_PROTOCOL_SCSI, Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be transparent till we get into the driver. First got this: [ 566.531100] BUG: sleeping function called from invalid context at mm/slab.h:421 [ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name: bsg_api_test [ 566.531460] 1 lock held by bsg_api_test/3104: [ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at: hctx_lock+0x30/0x118 [ 566.531498] Preemption disabled at: [ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218 [ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW 4.19.0-rc6-bb-next+ #1 [ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR) [ 566.531533] Call Trace: [ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8) [ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8 [ 566.531565] [<00196410>] ___might_sleep+0x280/0x298 [ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560 [ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0 [ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118 [ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670 [ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130 [ 566.531615] [<00820dfe>] blk_mq_sched_dispatch_requests+0x156/0x1a0 [ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160 [ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218 [ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0 [ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8 [ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80 [ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8 [ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500 [ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710 [ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0 [ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40 [ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0 [ 566.531815] 1 lock held by bsg_api_test/3104: [ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at: hctx_lock+0x30/0x118 >>> >>> The first one is an easy fix, not sure how I missed that. The other >>> one I have no idea, any chance you could try with this one: >>> >>> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=142dc9f36e3113b6a76d472978c33c8c2a2b702c >>> >>> which fixes the first one, and also corrects a wrong end_io call, >>> but I don't think that's the cause of the above. >>> >>> If it crashes, can you figure out where in the source that is? >>> Basically just do >>> >>> gdb vmlinux >>> l *zfcp_fc_exec_bsg_job+0x116 >>> >>> assuming that works fine on s390 :-) >>> >> >> So I tried 4.19.0 with only the two patches from you: >> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa >> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=142dc9f36e3113b6a76d472978c33c8c2a2b702c >> >> This fixed the first warning from before, as you suggested, but it still >> crash like this: >> >> [ ] Unable to handle kernel pointer dereference in virtual kernel address >> space >> [ ] Failing address: TEID: 0483 >> [ ] Fault in home space mode while using kernel ASCE. >> [ ] AS:025f0007 R3:dffb8007 S:dffbf000 >> P:013d >> [ ] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC >> [ ] Modules linked in: >> [ ] CPU: 2 PID: 609 Comm: kworker/2:1H Kdump: loaded Tainted: GW >> 4.19.0-bb-next+ #1 >> [ ] Hardware name: IBM 3906 M03 704 (LPAR) >> [ ] Workqueue: kblockd blk_mq_run_work_fn >> [ ] Krnl PSW : 0704e0018000 03ff806a6b40 >> (zfcp_fc_exec_bsg_job+0x1c0/0x440 [zfcp]) >> [ ]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 >> [ ] Krnl GPRS: 83e0f3c0 >> 0300 >> [ ]0300 0
Re: [PATCH] bsg: convert to use blk-mq
On Thu, Oct 25, 2018 at 05:12:59PM -0600, Jens Axboe wrote: > On 10/23/18 12:07 PM, Jens Axboe wrote: > > On 10/23/18 11:40 AM, Benjamin Block wrote: > >> > >> So I tried 4.19.0 with only the two patches from you: > >> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa > >> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=142dc9f36e3113b6a76d472978c33c8c2a2b702c > >> > >> This fixed the first warning from before, as you suggested, but it still > >> crash like this: > >> > >> [ ] Unable to handle kernel pointer dereference in virtual kernel address > >> space > >> [ ] Failing address: TEID: 0483 > >> [ ] Fault in home space mode while using kernel ASCE. > >> [ ] AS:025f0007 R3:dffb8007 S:dffbf000 > >> P:013d > >> [ ] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC > >> [ ] Modules linked in: > >> [ ] CPU: 2 PID: 609 Comm: kworker/2:1H Kdump: loaded Tainted: GW > >> 4.19.0-bb-next+ #1 > >> [ ] Hardware name: IBM 3906 M03 704 (LPAR) > >> [ ] Workqueue: kblockd blk_mq_run_work_fn > >> [ ] Krnl PSW : 0704e0018000 03ff806a6b40 > >> (zfcp_fc_exec_bsg_job+0x1c0/0x440 [zfcp]) > >> [ ]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 > >> [ ] Krnl GPRS: 83e0f3c0 > >> 0300 > >> [ ]0300 03ff806a6b3a a86b5948 > >> a86b5988 > >> [ ]83e0f3f0 a86b5938 > >> 984aee80 > >> [ ]a86b5800 03ff806ba950 03ff806a6b3a > >> 98a5ed88 > >> [ ] Krnl Code: 03ff806a6b30: b9040029lgr %r2,%r9 > >>03ff806a6b34: c0e58b7ebrasl > >> %r14,3ff80698230 > >> #03ff806a6b3a: e310f0a4lg %r1,160(%r15) > >> >03ff806a6b40: e3109024stg %r1,0(%r9) > >>03ff806a6b46: 4120a040la %r2,64(%r10) > >>03ff806a6b4a: c0e58ae7brasl > >> %r14,3ff80698118 > >>03ff806a6b50: e310a044lg %r1,64(%r10) > >>03ff806a6b56: e310f0a00024stg %r1,160(%r15) > >> [ ] Call Trace: > >> [ ] ([<03ff806a6aa2>] zfcp_fc_exec_bsg_job+0x122/0x440 [zfcp]) > >> [ ] [<03ff8061e928>] fc_bsg_dispatch+0x310/0x398 [scsi_transport_fc] > >> [ ] [<00d2995a>] bsg_queue_rq+0x15a/0x198 > >> [ ] [<00d03566>] blk_mq_dispatch_rq_list+0x966/0xf90 > >> [ ] [<00d0e37a>] blk_mq_sched_dispatch_requests+0x3fa/0x410 > >> [ ] [<00cfc230>] __blk_mq_run_hw_queue+0x218/0x248 > >> [ ] [<001cb124>] process_one_work+0x8c4/0xe90 > >> [ ] [<001cbe58>] worker_thread+0x768/0xbb0 > >> [ ] [<001dc67a>] kthread+0x22a/0x248 > >> [ ] [<0137b812>] kernel_thread_starter+0x6/0xc > >> [ ] [<0137b80c>] kernel_thread_starter+0x0/0xc > >> [ ] INFO: lockdep is turned off. > >> [ ] Last Breaking-Event-Address: > >> [ ] [<005d9b08>] __asan_store8+0x98/0xa0 > >> [ ] > >> [ ] Kernel panic - not syncing: Fatal exception: panic_on_oops > >> > >> zfcp_fc_exec_bsg_job+0x1c0 is here: > >> > >> int zfcp_fc_exec_bsg_job(struct bsg_job *job) > >> { > >> struct Scsi_Host *shost; > >> struct zfcp_adapter *adapter; > >> struct zfcp_fsf_ct_els *ct_els = job->dd_data; > >> struct fc_bsg_request *bsg_request = job->request; > >> struct fc_rport *rport = fc_bsg_to_rport(job); > >> > >> shost = rport ? rport_to_shost(rport) : fc_bsg_to_shost(job); > >> adapter = (struct zfcp_adapter *)shost->hostdata[0]; > >> > >> if (!(atomic_read(&adapter->status) & ZFCP_STATUS_COMMON_OPEN)) > >> return -EINVAL; > >> > >> ==> ct_els->req = job->request_payload.sg_list; > >> ct_els->resp = job->reply_payload.sg_list; > >> ct_els->handler_data = job; > >> > >> switch (bsg_request->msgcode) { > >> case FC_BSG_RPT_ELS: > >> case FC_BSG_HST_ELS_NOLOGIN: > >> return zfcp_fc_exec_els_job(job, adapter); > >> case FC_BSG_RPT_CT: > >> case FC_BSG_HST_CT: > >> return zfcp_fc_exec_ct_job(job, adapter); > >> default: > >> return -EINVAL; > >> } > >> } > >> > >> I took a dump to find out how struct bsg_job looks like when it crashes > >> (register clobbering isn't as bad here and I verified that job->dev is > >> valid). > >> > >> crash> print *((struct bsg_job *)0xa86b5938) > >> $5 = { > >> dev = 0x9af10358, > >> kref = { > >> refcount = { > >> refs = { > >> counter = 0x1 > >> } > >>
Re: [PATCH] bsg: convert to use blk-mq
On 10/26/18 10:06 AM, Benjamin Block wrote: > On Thu, Oct 25, 2018 at 05:12:59PM -0600, Jens Axboe wrote: >> On 10/23/18 12:07 PM, Jens Axboe wrote: >>> On 10/23/18 11:40 AM, Benjamin Block wrote: So I tried 4.19.0 with only the two patches from you: http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=142dc9f36e3113b6a76d472978c33c8c2a2b702c This fixed the first warning from before, as you suggested, but it still crash like this: [ ] Unable to handle kernel pointer dereference in virtual kernel address space [ ] Failing address: TEID: 0483 [ ] Fault in home space mode while using kernel ASCE. [ ] AS:025f0007 R3:dffb8007 S:dffbf000 P:013d [ ] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ ] Modules linked in: [ ] CPU: 2 PID: 609 Comm: kworker/2:1H Kdump: loaded Tainted: GW 4.19.0-bb-next+ #1 [ ] Hardware name: IBM 3906 M03 704 (LPAR) [ ] Workqueue: kblockd blk_mq_run_work_fn [ ] Krnl PSW : 0704e0018000 03ff806a6b40 (zfcp_fc_exec_bsg_job+0x1c0/0x440 [zfcp]) [ ]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 [ ] Krnl GPRS: 83e0f3c0 0300 [ ]0300 03ff806a6b3a a86b5948 a86b5988 [ ]83e0f3f0 a86b5938 984aee80 [ ]a86b5800 03ff806ba950 03ff806a6b3a 98a5ed88 [ ] Krnl Code: 03ff806a6b30: b9040029lgr %r2,%r9 03ff806a6b34: c0e58b7ebrasl %r14,3ff80698230 #03ff806a6b3a: e310f0a4lg %r1,160(%r15) >03ff806a6b40: e3109024stg %r1,0(%r9) 03ff806a6b46: 4120a040la %r2,64(%r10) 03ff806a6b4a: c0e58ae7brasl %r14,3ff80698118 03ff806a6b50: e310a044lg %r1,64(%r10) 03ff806a6b56: e310f0a00024stg %r1,160(%r15) [ ] Call Trace: [ ] ([<03ff806a6aa2>] zfcp_fc_exec_bsg_job+0x122/0x440 [zfcp]) [ ] [<03ff8061e928>] fc_bsg_dispatch+0x310/0x398 [scsi_transport_fc] [ ] [<00d2995a>] bsg_queue_rq+0x15a/0x198 [ ] [<00d03566>] blk_mq_dispatch_rq_list+0x966/0xf90 [ ] [<00d0e37a>] blk_mq_sched_dispatch_requests+0x3fa/0x410 [ ] [<00cfc230>] __blk_mq_run_hw_queue+0x218/0x248 [ ] [<001cb124>] process_one_work+0x8c4/0xe90 [ ] [<001cbe58>] worker_thread+0x768/0xbb0 [ ] [<001dc67a>] kthread+0x22a/0x248 [ ] [<0137b812>] kernel_thread_starter+0x6/0xc [ ] [<0137b80c>] kernel_thread_starter+0x0/0xc [ ] INFO: lockdep is turned off. [ ] Last Breaking-Event-Address: [ ] [<005d9b08>] __asan_store8+0x98/0xa0 [ ] [ ] Kernel panic - not syncing: Fatal exception: panic_on_oops zfcp_fc_exec_bsg_job+0x1c0 is here: int zfcp_fc_exec_bsg_job(struct bsg_job *job) { struct Scsi_Host *shost; struct zfcp_adapter *adapter; struct zfcp_fsf_ct_els *ct_els = job->dd_data; struct fc_bsg_request *bsg_request = job->request; struct fc_rport *rport = fc_bsg_to_rport(job); shost = rport ? rport_to_shost(rport) : fc_bsg_to_shost(job); adapter = (struct zfcp_adapter *)shost->hostdata[0]; if (!(atomic_read(&adapter->status) & ZFCP_STATUS_COMMON_OPEN)) return -EINVAL; ==> ct_els->req = job->request_payload.sg_list; ct_els->resp = job->reply_payload.sg_list; ct_els->handler_data = job; switch (bsg_request->msgcode) { case FC_BSG_RPT_ELS: case FC_BSG_HST_ELS_NOLOGIN: return zfcp_fc_exec_els_job(job, adapter); case FC_BSG_RPT_CT: case FC_BSG_HST_CT: return zfcp_fc_exec_ct_job(job, adapter); default: return -EINVAL; } } I took a dump to find out how struct bsg_job looks like when it crashes (register clobbering isn't as bad here and I verified that job->dev is valid). crash> print *((struct bsg_job *)0xa86b5938) $5 = { dev = 0x9af10358, kref = { refcount = { refs = {
Re: [PATCH] bsg: convert to use blk-mq
On Fri, Oct 26, 2018 at 10:08:30AM -0600, Jens Axboe wrote: > On 10/26/18 10:06 AM, Benjamin Block wrote: > > On Thu, Oct 25, 2018 at 05:12:59PM -0600, Jens Axboe wrote: > >> On 10/23/18 12:07 PM, Jens Axboe wrote: > >>> On 10/23/18 11:40 AM, Benjamin Block wrote: > > So I tried 4.19.0 with only the two patches from you: > http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa > http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=142dc9f36e3113b6a76d472978c33c8c2a2b702c > > This fixed the first warning from before, as you suggested, but it still > crash like this: > > [ ] Unable to handle kernel pointer dereference in virtual kernel > address space > [ ] Failing address: TEID: 0483 > [ ] Fault in home space mode while using kernel ASCE. > [ ] AS:025f0007 R3:dffb8007 S:dffbf000 > P:013d > [ ] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ ] Modules linked in: > [ ] CPU: 2 PID: 609 Comm: kworker/2:1H Kdump: loaded Tainted: GW > 4.19.0-bb-next+ #1 > [ ] Hardware name: IBM 3906 M03 704 (LPAR) > [ ] Workqueue: kblockd blk_mq_run_work_fn > [ ] Krnl PSW : 0704e0018000 03ff806a6b40 > (zfcp_fc_exec_bsg_job+0x1c0/0x440 [zfcp]) > [ ]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 > EA:3 > [ ] Krnl GPRS: 83e0f3c0 > 0300 > [ ]0300 03ff806a6b3a a86b5948 > a86b5988 > [ ]83e0f3f0 a86b5938 > 984aee80 > [ ]a86b5800 03ff806ba950 03ff806a6b3a > 98a5ed88 > [ ] Krnl Code: 03ff806a6b30: b9040029lgr %r2,%r9 > 03ff806a6b34: c0e58b7ebrasl > %r14,3ff80698230 > #03ff806a6b3a: e310f0a4lg > %r1,160(%r15) > >03ff806a6b40: e3109024stg %r1,0(%r9) > 03ff806a6b46: 4120a040la %r2,64(%r10) > 03ff806a6b4a: c0e58ae7brasl > %r14,3ff80698118 > 03ff806a6b50: e310a044lg %r1,64(%r10) > 03ff806a6b56: e310f0a00024stg > %r1,160(%r15) > [ ] Call Trace: > [ ] ([<03ff806a6aa2>] zfcp_fc_exec_bsg_job+0x122/0x440 [zfcp]) > [ ] [<03ff8061e928>] fc_bsg_dispatch+0x310/0x398 [scsi_transport_fc] > [ ] [<00d2995a>] bsg_queue_rq+0x15a/0x198 > [ ] [<00d03566>] blk_mq_dispatch_rq_list+0x966/0xf90 > [ ] [<00d0e37a>] blk_mq_sched_dispatch_requests+0x3fa/0x410 > [ ] [<00cfc230>] __blk_mq_run_hw_queue+0x218/0x248 > [ ] [<001cb124>] process_one_work+0x8c4/0xe90 > [ ] [<001cbe58>] worker_thread+0x768/0xbb0 > [ ] [<001dc67a>] kthread+0x22a/0x248 > [ ] [<0137b812>] kernel_thread_starter+0x6/0xc > [ ] [<0137b80c>] kernel_thread_starter+0x0/0xc > [ ] INFO: lockdep is turned off. > [ ] Last Breaking-Event-Address: > [ ] [<005d9b08>] __asan_store8+0x98/0xa0 > [ ] > [ ] Kernel panic - not syncing: Fatal exception: panic_on_oops > > zfcp_fc_exec_bsg_job+0x1c0 is here: > > int zfcp_fc_exec_bsg_job(struct bsg_job *job) > { > struct Scsi_Host *shost; > struct zfcp_adapter *adapter; > struct zfcp_fsf_ct_els *ct_els = job->dd_data; > struct fc_bsg_request *bsg_request = job->request; > struct fc_rport *rport = fc_bsg_to_rport(job); > > shost = rport ? rport_to_shost(rport) : fc_bsg_to_shost(job); > adapter = (struct zfcp_adapter *)shost->hostdata[0]; > > if (!(atomic_read(&adapter->status) & > ZFCP_STATUS_COMMON_OPEN)) > return -EINVAL; > > ==> ct_els->req = job->request_payload.sg_list; > ct_els->resp = job->reply_payload.sg_list; > ct_els->handler_data = job; > > switch (bsg_request->msgcode) { > case FC_BSG_RPT_ELS: > case FC_BSG_HST_ELS_NOLOGIN: > return zfcp_fc_exec_els_job(job, adapter); > case FC_BSG_RPT_CT: > case FC_BSG_HST_CT: > return zfcp_fc_exec_ct_job(job, adapter); > default: > return -EINVAL; > } > } > > I took a dump to find out how struct bsg_job looks like when it cra