linux-stable.git/drivers/scsi/device_handler, branch v6.2.2

scsi: device_handler: alua: Remove a might_sleep() annotation

2023-01-19T00:16:02+00:00

The might_sleep() annotation in alua_rtpg_queue() is not correct since the
command completion code may call this function from atomic context.
Calling alua_rtpg_queue() from atomic context in the command completion
path is fine since request submitters must hold an sdev reference until
command execution has completed. This patch fixes the following kernel
complaint:

BUG: sleeping function called from invalid context at drivers/scsi/device_handler/scsi_dh_alua.c:992
Call Trace:
 dump_stack_lvl+0xac/0x100
 __might_resched+0x284/0x2c8
 alua_rtpg_queue+0x3c/0x98 [scsi_dh_alua]
 alua_check+0x122/0x250 [scsi_dh_alua]
 alua_check_sense+0x172/0x228 [scsi_dh_alua]
 scsi_check_sense+0x8a/0x2e0
 scsi_decide_disposition+0x286/0x298
 scsi_complete+0x6a/0x108
 blk_complete_reqs+0x6e/0x88
 __do_softirq+0x13e/0x6b8
 __irq_exit_rcu+0x14a/0x170
 irq_exit_rcu+0x22/0x50
 do_ext_irq+0x10a/0x1d0

Link: https://lore.kernel.org/r/20230118180557.1212577-1-bvanassche@acm.org
Reported-by: Steffen Maier 
Reviewed-by: Martin Wilck 
Tested-by: Steffen Maier 
Signed-off-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen

scsi: device_handler: alua: Call scsi_device_put() from non-atomic context

2022-11-26T00:35:16+00:00

Since commit f93ed747e2c7 ("scsi: core: Release SCSI devices
synchronously"), scsi_device_put() might sleep. Avoid calling it from
alua_rtpg_queue() with the pg_lock held. The lock only pretects h->pg,
anyway. To avoid the pg being freed under us, because of a race with
another thread, take a temporary reference. In alua_rtpg_queue(), verify
that the pg still belongs to the sdev being passed before actually queueing
the RTPG.

This patch fixes the following smatch warning:

drivers/scsi/device_handler/scsi_dh_alua.c:1013 alua_rtpg_queue() warn: sleeping in atomic context

alua_check_vpd() <- disables preempt
-> alua_rtpg_queue()
   -> scsi_device_put()

Cc: Martin Wilck 
Cc: Hannes Reinecke 
Cc: Sachin Sant 
Cc: Benjamin Block 
Suggested-by: Martin Wilck 
Reported-by: Dan Carpenter 
Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20221117183626.2656196-3-bvanassche@acm.org
Tested-by: Sachin Sant 
Signed-off-by: Martin K. Petersen

scsi: device_handler: alua: Revert "Move a scsi_device_put() call out of alua_check_vpd()"

2022-11-26T00:35:03+00:00

There is a bug in commit 0b25e17e9018 ("scsi: alua: Move a
scsi_device_put() call out of alua_check_vpd()"): that patch may cause
alua_rtpg_queue() callers to call scsi_device_put() even if that function
should not be called. Revert that commit to prepare for a different
solution.

Cc: Hannes Reinecke 
Cc: Martin Wilck 
Cc: Sachin Sant 
Cc: Benjamin Block 
Reported-by: Sachin Sant 
Reported-by: Benjamin Block 
Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20221117183626.2656196-2-bvanassche@acm.org
Tested-by: Sachin Sant 
Signed-off-by: Martin K. Petersen

scsi: alua: Move a scsi_device_put() call out of alua_rtpg_select_sdev()

2022-11-08T03:34:39+00:00

Move a scsi_device_put() call from alua_rtpg_select_sdev() to its
callers. Fixes the following smatch complaint:

drivers/scsi/device_handler/scsi_dh_alua.c:853 alua_rtpg_select_sdev() warn: sleeping in atomic context

alua_rtpg_work() <- disables preempt
-> alua_rtpg_select_sdev()
   -> scsi_device_put()

Cc: Hannes Reinecke 
Cc: Dan Carpenter 
Reported-by: Dan Carpenter 
Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20221031224728.2607760-3-bvanassche@acm.org
Signed-off-by: Martin K. Petersen

scsi: alua: Move a scsi_device_put() call out of alua_check_vpd()

2022-11-08T03:34:38+00:00

Fix the following smatch warning:

drivers/scsi/device_handler/scsi_dh_alua.c:1013 alua_rtpg_queue() warn: sleeping in atomic context

alua_check_vpd() <- disables preempt
-> alua_rtpg_queue()
   -> scsi_device_put()

Cc: Hannes Reinecke 
Cc: Dan Carpenter 
Reported-by: Dan Carpenter 
Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20221031224728.2607760-2-bvanassche@acm.org
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen

scsi/device_handlers: Use the new blk_opf_t type

2022-07-14T18:14:32+00:00

Improve static type checking by using the new blk_opf_t type for variables
that represent request flags.

Cc: Hannes Reinecke 
Cc: Martin Wilck 
Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20220714180729.1065367-43-bvanassche@acm.org
Signed-off-by: Jens Axboe

scsi: scsi_dh_alua: Properly handle the ALUA transitioning state

2022-05-02T23:52:13+00:00

The handling of the ALUA transitioning state is currently broken. When a
target goes into this state, it is expected that the target is allowed to
stay in this state for the implicit transition timeout without a path
failure. The handler has this logic, but it gets skipped currently.

When the target transitions, there is in-flight I/O from the initiator. The
first of these responses from the target will be a unit attention letting
the initiator know that the ALUA state has changed.  The remaining
in-flight I/Os, before the initiator finds out that the portal state has
changed, will return not ready, ALUA state is transitioning. The portal
state will change to SCSI_ACCESS_STATE_TRANSITIONING. This will lead to all
new I/O immediately failing the path unexpectedly. The path failure happens
in less than a second instead of the expected successes until the
transition timer is exceeded.

Allow I/Os to continue while the path is in the ALUA transitioning
state. The handler already takes care of a target that stays in the
transitioning state for too long by changing the state to ALUA state
standby once the transition timeout is exceeded at which point the path
will fail.

Link: https://lore.kernel.org/r/CAHZQxy+4sTPz9+pY3=7VJH+CLUJsDct81KtnR2be8ycN5mhqTg@mail.gmail.com
Reviewed-by: Hannes Reinecke 
Acked-by: Krishna Kant 
Acked-by: Seamus Connor 
Signed-off-by: Brian Bunker 
Signed-off-by: Martin K. Petersen

scsi: scsi_dh_rdac: Avoid crash during rdac_bus_attach()

2021-07-30T01:58:35+00:00

The following BUG_ON() was observed during RDAC scan:

[595952.944297] kernel BUG at drivers/scsi/device_handler/scsi_dh_rdac.c:427!
[595952.951143] Internal error: Oops - BUG: 0 [#1] SMP
......
[595953.251065] Call trace:
[595953.259054]  check_ownership+0xb0/0x118
[595953.269794]  rdac_bus_attach+0x1f0/0x4b0
[595953.273787]  scsi_dh_handler_attach+0x3c/0xe8
[595953.278211]  scsi_dh_add_device+0xc4/0xe8
[595953.282291]  scsi_sysfs_add_sdev+0x8c/0x2a8
[595953.286544]  scsi_probe_and_add_lun+0x9fc/0xd00
[595953.291142]  __scsi_scan_target+0x598/0x630
[595953.295395]  scsi_scan_target+0x120/0x130
[595953.299481]  fc_user_scan+0x1a0/0x1c0 [scsi_transport_fc]
[595953.304944]  store_scan+0xb0/0x108
[595953.308420]  dev_attr_store+0x44/0x60
[595953.312160]  sysfs_kf_write+0x58/0x80
[595953.315893]  kernfs_fop_write+0xe8/0x1f0
[595953.319888]  __vfs_write+0x60/0x190
[595953.323448]  vfs_write+0xac/0x1c0
[595953.326836]  ksys_write+0x74/0xf0
[595953.330221]  __arm64_sys_write+0x24/0x30

Code is in check_ownership:

	list_for_each_entry_rcu(tmp, &h->ctlr->dh_list, node) {
		/* h->sdev should always be valid */
		BUG_ON(!tmp->sdev);
		tmp->sdev->access_state = access_state;
	}

	rdac_bus_attach
		initialize_controller
			list_add_rcu(&h->node, &h->ctlr->dh_list);
			h->sdev = sdev;

	rdac_bus_detach
		list_del_rcu(&h->node);
		h->sdev = NULL;

Fix the race between rdac_bus_attach() and rdac_bus_detach() where h->sdev
is NULL when processing the RDAC attach.

Link: https://lore.kernel.org/r/20210113063103.2698953-1-yebin10@huawei.com
Reviewed-by: Bart Van Assche 
Signed-off-by: Ye Bin 
Signed-off-by: Martin K. Petersen

scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()

2021-06-08T01:48:16+00:00

The "retval" variable needs to be signed for the error handling to work.

Link: https://lore.kernel.org/r/YLjMEAFNxOas1mIp@mwanda
Fixes: 7e26e3ea0287 ("scsi: scsi_dh_alua: Check for negative result value")
Reviewed-by: Martin Wilck 
Signed-off-by: Dan Carpenter 
Signed-off-by: Martin K. Petersen

scsi: scsi_dh_alua: Check for negative result value

2021-06-01T02:48:21+00:00

scsi_execute() will now return a negative error if there was an error prior
to command submission; evaluate that instead if checking for DRIVER_ERROR.

[mkp: build fix]

Link: https://lore.kernel.org/r/20210427083046.31620-6-hare@suse.de
Signed-off-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen