* [PATCH] IB/srp: Process REQ_PREEMPT requests correctly
@ 2015-01-29 13:02 Bart Van Assche
[not found] ` <54CA2F48.605-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-01-29 19:38 ` Mike Christie
0 siblings, 2 replies; 6+ messages in thread
From: Bart Van Assche @ 2015-01-29 13:02 UTC (permalink / raw)
To: Roland Dreier; +Cc: Max Gurtuvoy, Sagi Grimberg, linux-rdma, linux-scsi
Delay REQ_PREEMPT requests submitted against a blocked device
until the device is unblocked by returning SCSI_MLQUEUE_HOST_BUSY
to the SCSI mid-layer. This avoids that a rescan shortly after a
cable pull sporadically triggers the following kernel oops:
BUG: unable to handle kernel paging request at ffffc9001a6bc084
IP: [<ffffffffa04e08f2>] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib]
Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100)
Call Trace:
[<ffffffffa0718135>] srp_post_send+0x65/0x70 [ib_srp]
[<ffffffffa071b9df>] srp_queuecommand+0x1cf/0x3e0 [ib_srp]
[<ffffffffa0001ff1>] scsi_dispatch_cmd+0x101/0x280 [scsi_mod]
[<ffffffffa0009ad1>] scsi_request_fn+0x411/0x4d0 [scsi_mod]
[<ffffffff81223b37>] __blk_run_queue+0x27/0x30
[<ffffffff8122a8d2>] blk_execute_rq_nowait+0x82/0x110
[<ffffffff8122a9c2>] blk_execute_rq+0x62/0xf0
[<ffffffffa000b0e8>] scsi_execute+0xe8/0x190 [scsi_mod]
[<ffffffffa000b2f3>] scsi_execute_req+0xa3/0x130 [scsi_mod]
[<ffffffffa000c1aa>] scsi_probe_lun+0x17a/0x450 [scsi_mod]
[<ffffffffa000ce86>] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod]
[<ffffffffa000dc2f>] __scsi_scan_target+0xdf/0x1f0 [scsi_mod]
[<ffffffffa000dfa3>] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod]
[<ffffffffa000edfb>] scsi_scan+0xdb/0xe0 [scsi_mod]
[<ffffffffa000ee13>] store_scan+0x13/0x20 [scsi_mod]
[<ffffffff811c8d9b>] sysfs_write_file+0xcb/0x160
[<ffffffff811589de>] vfs_write+0xce/0x140
[<ffffffff81158b53>] sys_write+0x53/0xa0
[<ffffffff81464592>] system_call_fastpath+0x16/0x1b
[<00007f611c9d9300>] 0x7f611c9d92ff
Reported-by: Max Gurtuvoy <maxg@mellanox.com>
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: <stable@vger.kernel.org>
---
drivers/infiniband/ulp/srp/ib_srp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
index 0747c05..77a7a2f 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2003,8 +2003,13 @@ static int srp_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd)
if (in_scsi_eh)
mutex_lock(&rport->mutex);
+ /*
+ * The "blocked" state of SCSI devices is ignored by the SCSI core for
+ * REQ_PREEMPT requests. Hence the explicit check below for the SCSI
+ * device state.
+ */
scmnd->result = srp_chkready(target->rport);
- if (unlikely(scmnd->result))
+ if (unlikely(scmnd->result != 0 || scsi_device_blocked(scmnd->device)))
goto err;
WARN_ON_ONCE(scmnd->request->tag < 0);
--
2.1.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] IB/srp: Process REQ_PREEMPT requests correctly
[not found] ` <54CA2F48.605-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
@ 2015-01-29 13:44 ` Sagi Grimberg
0 siblings, 0 replies; 6+ messages in thread
From: Sagi Grimberg @ 2015-01-29 13:44 UTC (permalink / raw)
To: Bart Van Assche, Roland Dreier
Cc: Max Gurtuvoy, Sagi Grimberg, linux-rdma,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
On 1/29/2015 3:02 PM, Bart Van Assche wrote:
> Delay REQ_PREEMPT requests submitted against a blocked device
> until the device is unblocked by returning SCSI_MLQUEUE_HOST_BUSY
> to the SCSI mid-layer. This avoids that a rescan shortly after a
> cable pull sporadically triggers the following kernel oops:
>
> BUG: unable to handle kernel paging request at ffffc9001a6bc084
> IP: [<ffffffffa04e08f2>] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib]
> Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100)
> Call Trace:
> [<ffffffffa0718135>] srp_post_send+0x65/0x70 [ib_srp]
> [<ffffffffa071b9df>] srp_queuecommand+0x1cf/0x3e0 [ib_srp]
> [<ffffffffa0001ff1>] scsi_dispatch_cmd+0x101/0x280 [scsi_mod]
> [<ffffffffa0009ad1>] scsi_request_fn+0x411/0x4d0 [scsi_mod]
> [<ffffffff81223b37>] __blk_run_queue+0x27/0x30
> [<ffffffff8122a8d2>] blk_execute_rq_nowait+0x82/0x110
> [<ffffffff8122a9c2>] blk_execute_rq+0x62/0xf0
> [<ffffffffa000b0e8>] scsi_execute+0xe8/0x190 [scsi_mod]
> [<ffffffffa000b2f3>] scsi_execute_req+0xa3/0x130 [scsi_mod]
> [<ffffffffa000c1aa>] scsi_probe_lun+0x17a/0x450 [scsi_mod]
> [<ffffffffa000ce86>] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod]
> [<ffffffffa000dc2f>] __scsi_scan_target+0xdf/0x1f0 [scsi_mod]
> [<ffffffffa000dfa3>] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod]
> [<ffffffffa000edfb>] scsi_scan+0xdb/0xe0 [scsi_mod]
> [<ffffffffa000ee13>] store_scan+0x13/0x20 [scsi_mod]
> [<ffffffff811c8d9b>] sysfs_write_file+0xcb/0x160
> [<ffffffff811589de>] vfs_write+0xce/0x140
> [<ffffffff81158b53>] sys_write+0x53/0xa0
> [<ffffffff81464592>] system_call_fastpath+0x16/0x1b
> [<00007f611c9d9300>] 0x7f611c9d92ff
>
> Reported-by: Max Gurtuvoy <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Cc: Sagi Grimberg <sagig-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> ---
> drivers/infiniband/ulp/srp/ib_srp.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
> index 0747c05..77a7a2f 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -2003,8 +2003,13 @@ static int srp_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd)
> if (in_scsi_eh)
> mutex_lock(&rport->mutex);
>
> + /*
> + * The "blocked" state of SCSI devices is ignored by the SCSI core for
> + * REQ_PREEMPT requests. Hence the explicit check below for the SCSI
> + * device state.
> + */
> scmnd->result = srp_chkready(target->rport);
> - if (unlikely(scmnd->result))
> + if (unlikely(scmnd->result != 0 || scsi_device_blocked(scmnd->device)))
> goto err;
>
> WARN_ON_ONCE(scmnd->request->tag < 0);
>
Yep...
Reviewed-by: Sagi Grimberg <sagig-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] IB/srp: Process REQ_PREEMPT requests correctly
2015-01-29 13:02 [PATCH] IB/srp: Process REQ_PREEMPT requests correctly Bart Van Assche
[not found] ` <54CA2F48.605-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
@ 2015-01-29 19:38 ` Mike Christie
2015-01-30 2:06 ` Mike Christie
1 sibling, 1 reply; 6+ messages in thread
From: Mike Christie @ 2015-01-29 19:38 UTC (permalink / raw)
To: Bart Van Assche
Cc: Roland Dreier, Max Gurtuvoy, Sagi Grimberg, linux-rdma, linux-scsi
On 1/29/15, 7:02 AM, Bart Van Assche wrote:
> Delay REQ_PREEMPT requests submitted against a blocked device
> until the device is unblocked by returning SCSI_MLQUEUE_HOST_BUSY
> to the SCSI mid-layer. This avoids that a rescan shortly after a
> cable pull sporadically triggers the following kernel oops:
>
> BUG: unable to handle kernel paging request at ffffc9001a6bc084
> IP: [<ffffffffa04e08f2>] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib]
> Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100)
> Call Trace:
> [<ffffffffa0718135>] srp_post_send+0x65/0x70 [ib_srp]
> [<ffffffffa071b9df>] srp_queuecommand+0x1cf/0x3e0 [ib_srp]
> [<ffffffffa0001ff1>] scsi_dispatch_cmd+0x101/0x280 [scsi_mod]
> [<ffffffffa0009ad1>] scsi_request_fn+0x411/0x4d0 [scsi_mod]
> [<ffffffff81223b37>] __blk_run_queue+0x27/0x30
> [<ffffffff8122a8d2>] blk_execute_rq_nowait+0x82/0x110
> [<ffffffff8122a9c2>] blk_execute_rq+0x62/0xf0
> [<ffffffffa000b0e8>] scsi_execute+0xe8/0x190 [scsi_mod]
> [<ffffffffa000b2f3>] scsi_execute_req+0xa3/0x130 [scsi_mod]
> [<ffffffffa000c1aa>] scsi_probe_lun+0x17a/0x450 [scsi_mod]
> [<ffffffffa000ce86>] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod]
> [<ffffffffa000dc2f>] __scsi_scan_target+0xdf/0x1f0 [scsi_mod]
> [<ffffffffa000dfa3>] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod]
> [<ffffffffa000edfb>] scsi_scan+0xdb/0xe0 [scsi_mod]
> [<ffffffffa000ee13>] store_scan+0x13/0x20 [scsi_mod]
> [<ffffffff811c8d9b>] sysfs_write_file+0xcb/0x160
> [<ffffffff811589de>] vfs_write+0xce/0x140
> [<ffffffff81158b53>] sys_write+0x53/0xa0
> [<ffffffff81464592>] system_call_fastpath+0x16/0x1b
> [<00007f611c9d9300>] 0x7f611c9d92ff
>
> Reported-by: Max Gurtuvoy <maxg@mellanox.com>
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> Cc: Sagi Grimberg <sagig@mellanox.com>
> Cc: <stable@vger.kernel.org>
> ---
> drivers/infiniband/ulp/srp/ib_srp.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
> index 0747c05..77a7a2f 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -2003,8 +2003,13 @@ static int srp_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd)
> if (in_scsi_eh)
> mutex_lock(&rport->mutex);
>
> + /*
> + * The "blocked" state of SCSI devices is ignored by the SCSI core for
> + * REQ_PREEMPT requests. Hence the explicit check below for the SCSI
> + * device state.
> + */
> scmnd->result = srp_chkready(target->rport);
> - if (unlikely(scmnd->result))
> + if (unlikely(scmnd->result != 0 || scsi_device_blocked(scmnd->device)))
> goto err;
>
> WARN_ON_ONCE(scmnd->request->tag < 0);
>
What is the case where a driver blocks the device and can handle or
wants commands? iSCSI and FC also do not want commands, even PREEMPT
ones, at this time. It looks like they have been hitting internal checks
to prevent hitting similar issues.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] IB/srp: Process REQ_PREEMPT requests correctly
2015-01-29 19:38 ` Mike Christie
@ 2015-01-30 2:06 ` Mike Christie
2015-01-30 14:34 ` Bart Van Assche
0 siblings, 1 reply; 6+ messages in thread
From: Mike Christie @ 2015-01-30 2:06 UTC (permalink / raw)
To: Bart Van Assche
Cc: Roland Dreier, Max Gurtuvoy, Sagi Grimberg, linux-rdma, linux-scsi
On 1/29/15, 1:38 PM, Mike Christie wrote:
> On 1/29/15, 7:02 AM, Bart Van Assche wrote:
>> Delay REQ_PREEMPT requests submitted against a blocked device
>> until the device is unblocked by returning SCSI_MLQUEUE_HOST_BUSY
>> to the SCSI mid-layer. This avoids that a rescan shortly after a
>> cable pull sporadically triggers the following kernel oops:
>>
>> BUG: unable to handle kernel paging request at ffffc9001a6bc084
>> IP: [<ffffffffa04e08f2>] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib]
>> Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task
>> ffff880534aae100)
>> Call Trace:
>> [<ffffffffa0718135>] srp_post_send+0x65/0x70 [ib_srp]
>> [<ffffffffa071b9df>] srp_queuecommand+0x1cf/0x3e0 [ib_srp]
>> [<ffffffffa0001ff1>] scsi_dispatch_cmd+0x101/0x280 [scsi_mod]
>> [<ffffffffa0009ad1>] scsi_request_fn+0x411/0x4d0 [scsi_mod]
>> [<ffffffff81223b37>] __blk_run_queue+0x27/0x30
>> [<ffffffff8122a8d2>] blk_execute_rq_nowait+0x82/0x110
>> [<ffffffff8122a9c2>] blk_execute_rq+0x62/0xf0
>> [<ffffffffa000b0e8>] scsi_execute+0xe8/0x190 [scsi_mod]
>> [<ffffffffa000b2f3>] scsi_execute_req+0xa3/0x130 [scsi_mod]
>> [<ffffffffa000c1aa>] scsi_probe_lun+0x17a/0x450 [scsi_mod]
>> [<ffffffffa000ce86>] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod]
>> [<ffffffffa000dc2f>] __scsi_scan_target+0xdf/0x1f0 [scsi_mod]
>> [<ffffffffa000dfa3>] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod]
>> [<ffffffffa000edfb>] scsi_scan+0xdb/0xe0 [scsi_mod]
>> [<ffffffffa000ee13>] store_scan+0x13/0x20 [scsi_mod]
>> [<ffffffff811c8d9b>] sysfs_write_file+0xcb/0x160
>> [<ffffffff811589de>] vfs_write+0xce/0x140
>> [<ffffffff81158b53>] sys_write+0x53/0xa0
>> [<ffffffff81464592>] system_call_fastpath+0x16/0x1b
>> [<00007f611c9d9300>] 0x7f611c9d92ff
>>
>> Reported-by: Max Gurtuvoy <maxg@mellanox.com>
>> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
>> Cc: Sagi Grimberg <sagig@mellanox.com>
>> Cc: <stable@vger.kernel.org>
>> ---
>> drivers/infiniband/ulp/srp/ib_srp.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
>> b/drivers/infiniband/ulp/srp/ib_srp.c
>> index 0747c05..77a7a2f 100644
>> --- a/drivers/infiniband/ulp/srp/ib_srp.c
>> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
>> @@ -2003,8 +2003,13 @@ static int srp_queuecommand(struct Scsi_Host
>> *shost, struct scsi_cmnd *scmnd)
>> if (in_scsi_eh)
>> mutex_lock(&rport->mutex);
>>
>> + /*
>> + * The "blocked" state of SCSI devices is ignored by the SCSI
>> core for
>> + * REQ_PREEMPT requests. Hence the explicit check below for the SCSI
>> + * device state.
>> + */
>> scmnd->result = srp_chkready(target->rport);
>> - if (unlikely(scmnd->result))
>> + if (unlikely(scmnd->result != 0 ||
>> scsi_device_blocked(scmnd->device)))
>> goto err;
>>
>> WARN_ON_ONCE(scmnd->request->tag < 0);
>>
>
> What is the case where a driver blocks the device and can handle or
> wants commands? iSCSI and FC also do not want commands, even PREEMPT
> ones, at this time. It looks like they have been hitting internal checks
> to prevent hitting similar issues.
I think I figured this out. I think we want to change the
scsi_prep_state_check check instead of each driver/class.
It looks like for the SDEV_QUIESCE state we want to allow REQ_PREEMPT
commands. James would know best, but I think SPI needs that ability.
For SDEV_BLOCK/SDEV_CREATED_BLOCK, it looks like drivers/classes that
use that state do not want any commands to be queued at that time,
because the transport is normally down.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] IB/srp: Process REQ_PREEMPT requests correctly
2015-01-30 2:06 ` Mike Christie
@ 2015-01-30 14:34 ` Bart Van Assche
[not found] ` <54CB9670.6080108-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: Bart Van Assche @ 2015-01-30 14:34 UTC (permalink / raw)
To: Mike Christie
Cc: Roland Dreier, Max Gurtuvoy, Sagi Grimberg, linux-rdma, linux-scsi
On 01/30/15 03:06, Mike Christie wrote:
> I think I figured this out. I think we want to change the
> scsi_prep_state_check check instead of each driver/class.
>
> It looks like for the SDEV_QUIESCE state we want to allow REQ_PREEMPT
> commands. James would know best, but I think SPI needs that ability.
>
> For SDEV_BLOCK/SDEV_CREATED_BLOCK, it looks like drivers/classes that
> use that state do not want any commands to be queued at that time,
> because the transport is normally down.
Hello Mike,
Is something like the patch below what you had in mind ?
Bart.
[PATCH] Defer processing of REQ_PREEMPT requests for blocked devices
SCSI transport drivers and SCSI LLDs block a SCSI device if the
transport layer is not operational. This means that in this state
no requests should be processed, even if the REQ_PREEMPT flag has
been set. This patch avoids that a rescan shortly after a cable
pull sporadically triggers the following kernel oops:
BUG: unable to handle kernel paging request at ffffc9001a6bc084
IP: [<ffffffffa04e08f2>] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib]
Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100)
Call Trace:
[<ffffffffa0718135>] srp_post_send+0x65/0x70 [ib_srp]
[<ffffffffa071b9df>] srp_queuecommand+0x1cf/0x3e0 [ib_srp]
[<ffffffffa0001ff1>] scsi_dispatch_cmd+0x101/0x280 [scsi_mod]
[<ffffffffa0009ad1>] scsi_request_fn+0x411/0x4d0 [scsi_mod]
[<ffffffff81223b37>] __blk_run_queue+0x27/0x30
[<ffffffff8122a8d2>] blk_execute_rq_nowait+0x82/0x110
[<ffffffff8122a9c2>] blk_execute_rq+0x62/0xf0
[<ffffffffa000b0e8>] scsi_execute+0xe8/0x190 [scsi_mod]
[<ffffffffa000b2f3>] scsi_execute_req+0xa3/0x130 [scsi_mod]
[<ffffffffa000c1aa>] scsi_probe_lun+0x17a/0x450 [scsi_mod]
[<ffffffffa000ce86>] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod]
[<ffffffffa000dc2f>] __scsi_scan_target+0xdf/0x1f0 [scsi_mod]
[<ffffffffa000dfa3>] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod]
[<ffffffffa000edfb>] scsi_scan+0xdb/0xe0 [scsi_mod]
[<ffffffffa000ee13>] store_scan+0x13/0x20 [scsi_mod]
[<ffffffff811c8d9b>] sysfs_write_file+0xcb/0x160
[<ffffffff811589de>] vfs_write+0xce/0x140
[<ffffffff81158b53>] sys_write+0x53/0xa0
[<ffffffff81464592>] system_call_fastpath+0x16/0x1b
[<00007f611c9d9300>] 0x7f611c9d92ff
---
drivers/scsi/scsi_lib.c | 4 +++-
include/linux/blk_types.h | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 17bb541..7129701 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1311,9 +1311,11 @@ scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
"rejecting I/O to dead device\n");
ret = BLKPREP_KILL;
break;
- case SDEV_QUIESCE:
case SDEV_BLOCK:
case SDEV_CREATED_BLOCK:
+ ret = BLKPREP_DEFER;
+ break;
+ case SDEV_QUIESCE:
/*
* If the devices is blocked we defer normal commands.
*/
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index c294e3e..a1b25e3 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -181,7 +181,9 @@ enum rq_flag_bits {
__REQ_ELVPRIV, /* elevator private data attached */
__REQ_FAILED, /* set if the request failed */
__REQ_QUIET, /* don't worry about errors */
- __REQ_PREEMPT, /* set for "ide_preempt" requests */
+ __REQ_PREEMPT, /* set for "ide_preempt" requests and also
+ for requests for which the SCSI "quiesce"
+ state must be ignored. */
__REQ_ALLOCED, /* request came from our alloc pool */
__REQ_COPY_USER, /* contains copies of user pages */
__REQ_FLUSH_SEQ, /* request for flush sequence */
--
2.1.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] IB/srp: Process REQ_PREEMPT requests correctly
[not found] ` <54CB9670.6080108-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
@ 2015-01-30 20:18 ` Mike Christie
0 siblings, 0 replies; 6+ messages in thread
From: Mike Christie @ 2015-01-30 20:18 UTC (permalink / raw)
To: Bart Van Assche
Cc: Roland Dreier, Max Gurtuvoy, Sagi Grimberg, linux-rdma,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
On 01/30/2015 08:34 AM, Bart Van Assche wrote:
> On 01/30/15 03:06, Mike Christie wrote:
>> I think I figured this out. I think we want to change the
>> scsi_prep_state_check check instead of each driver/class.
>>
>> It looks like for the SDEV_QUIESCE state we want to allow REQ_PREEMPT
>> commands. James would know best, but I think SPI needs that ability.
>>
>> For SDEV_BLOCK/SDEV_CREATED_BLOCK, it looks like drivers/classes that
>> use that state do not want any commands to be queued at that time,
>> because the transport is normally down.
>
> Hello Mike,
>
> Is something like the patch below what you had in mind ?
>
> Bart.
>
> [PATCH] Defer processing of REQ_PREEMPT requests for blocked devices
>
> SCSI transport drivers and SCSI LLDs block a SCSI device if the
> transport layer is not operational. This means that in this state
> no requests should be processed, even if the REQ_PREEMPT flag has
> been set. This patch avoids that a rescan shortly after a cable
> pull sporadically triggers the following kernel oops:
>
> BUG: unable to handle kernel paging request at ffffc9001a6bc084
> IP: [<ffffffffa04e08f2>] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib]
> Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100)
> Call Trace:
> [<ffffffffa0718135>] srp_post_send+0x65/0x70 [ib_srp]
> [<ffffffffa071b9df>] srp_queuecommand+0x1cf/0x3e0 [ib_srp]
> [<ffffffffa0001ff1>] scsi_dispatch_cmd+0x101/0x280 [scsi_mod]
> [<ffffffffa0009ad1>] scsi_request_fn+0x411/0x4d0 [scsi_mod]
> [<ffffffff81223b37>] __blk_run_queue+0x27/0x30
> [<ffffffff8122a8d2>] blk_execute_rq_nowait+0x82/0x110
> [<ffffffff8122a9c2>] blk_execute_rq+0x62/0xf0
> [<ffffffffa000b0e8>] scsi_execute+0xe8/0x190 [scsi_mod]
> [<ffffffffa000b2f3>] scsi_execute_req+0xa3/0x130 [scsi_mod]
> [<ffffffffa000c1aa>] scsi_probe_lun+0x17a/0x450 [scsi_mod]
> [<ffffffffa000ce86>] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod]
> [<ffffffffa000dc2f>] __scsi_scan_target+0xdf/0x1f0 [scsi_mod]
> [<ffffffffa000dfa3>] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod]
> [<ffffffffa000edfb>] scsi_scan+0xdb/0xe0 [scsi_mod]
> [<ffffffffa000ee13>] store_scan+0x13/0x20 [scsi_mod]
> [<ffffffff811c8d9b>] sysfs_write_file+0xcb/0x160
> [<ffffffff811589de>] vfs_write+0xce/0x140
> [<ffffffff81158b53>] sys_write+0x53/0xa0
> [<ffffffff81464592>] system_call_fastpath+0x16/0x1b
> [<00007f611c9d9300>] 0x7f611c9d92ff
>
> ---
> drivers/scsi/scsi_lib.c | 4 +++-
> include/linux/blk_types.h | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 17bb541..7129701 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1311,9 +1311,11 @@ scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
> "rejecting I/O to dead device\n");
> ret = BLKPREP_KILL;
> break;
> - case SDEV_QUIESCE:
> case SDEV_BLOCK:
> case SDEV_CREATED_BLOCK:
> + ret = BLKPREP_DEFER;
> + break;
> + case SDEV_QUIESCE:
> /*
> * If the devices is blocked we defer normal commands.
> */
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index c294e3e..a1b25e3 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -181,7 +181,9 @@ enum rq_flag_bits {
> __REQ_ELVPRIV, /* elevator private data attached */
> __REQ_FAILED, /* set if the request failed */
> __REQ_QUIET, /* don't worry about errors */
> - __REQ_PREEMPT, /* set for "ide_preempt" requests */
> + __REQ_PREEMPT, /* set for "ide_preempt" requests and also
> + for requests for which the SCSI "quiesce"
> + state must be ignored. */
> __REQ_ALLOCED, /* request came from our alloc pool */
> __REQ_COPY_USER, /* contains copies of user pages */
> __REQ_FLUSH_SEQ, /* request for flush sequence */
>
Yeah. Did some basic tests and it works for me with iscsi and fc. Will
try to do some real testing over the weekend.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-01-30 20:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-29 13:02 [PATCH] IB/srp: Process REQ_PREEMPT requests correctly Bart Van Assche
[not found] ` <54CA2F48.605-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-01-29 13:44 ` Sagi Grimberg
2015-01-29 19:38 ` Mike Christie
2015-01-30 2:06 ` Mike Christie
2015-01-30 14:34 ` Bart Van Assche
[not found] ` <54CB9670.6080108-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-01-30 20:18 ` Mike Christie
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.