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=2b2ffa16193e9a69a076595ed64429b8cc9b42aa
> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions=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(>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
>
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=2b2ffa16193e9a69a076595ed64429b8cc9b42aa
http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions=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(>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 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=2b2ffa16193e9a69a076595ed64429b8cc9b42aa
> >> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions=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(>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/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=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=2b2ffa16193e9a69a076595ed64429b8cc9b42aa
>> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions=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
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=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/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=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 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=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: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=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 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=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/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=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=2b2ffa16193e9a69a076595ed64429b8cc9b42aa
> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions=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 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=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=2b2ffa16193e9a69a076595ed64429b8cc9b42aa
http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions=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:
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
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
> >
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:
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
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 = _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 (>mutex){+.+.}, at: >>>
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 = _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 (>mutex){+.+.}, at: > > kernfs_fop_write+0x258/0x288 > > [ 36.301202] #2: deb28615
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 = _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 (>mutex){+.+.}, at: > kernfs_fop_write+0x258/0x288 > [ 36.301202] #2: deb28615 (kn->count#52){.+.+}, at: > kernfs_fop_write+0x26e/0x288 > [ 36.301374] #3: 2ddb9663 (>mutex){}, at: > online_store+0x19c/0x3e8 > [ 36.301523] #4: 982b5ed9 (attribute_container_mutex){+.+.}, at: > attribute_container_add_device+0x3c/0x1d0 > [
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 = _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 (>mutex){+.+.}, at: kernfs_fop_write+0x258/0x288 [ 36.301202] #2: deb28615 (kn->count#52){.+.+}, at: kernfs_fop_write+0x26e/0x288 [ 36.301374] #3: 2ddb9663 (>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/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 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 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 = _mq_ops; -- Jens Axboe
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
