kernel/linux.git/include/target, branch v6.3.3

scsi: target: Fix multiple LUN_RESET handling

2023-05-11T14:17:14+00:00

[ Upstream commit 673db054d7a2b5a470d7a25baf65956d005ad729 ] This fixes a bug where an initiator thinks a LUN_RESET has cleaned up running commands when it hasn't. The bug was added in commit 51ec502a3266 ("target: Delete tmr from list before processing"). The problem occurs when: 1. We have N I/O cmds running in the target layer spread over 2 sessions. 2. The initiator sends a LUN_RESET for each session. 3. session1's LUN_RESET loops over all the running commands from both sessions and moves them to its local drain_task_list. 4. session2's LUN_RESET does not see the LUN_RESET from session1 because the commit above has it remove itself. session2 also does not see any commands since the other reset moved them off the state lists. 5. sessions2's LUN_RESET will then complete with a successful response. 6. sessions2's inititor believes the running commands on its session are now cleaned up due to the successful response and cleans up the running commands from its side. It then restarts them. 7. The commands do eventually complete on the backend and the target starts to return aborted task statuses for them. The initiator will either throw a invalid ITT error or might accidentally lookup a new task if the ITT has been reallocated already. Fix the bug by reverting the patch, and serialize the execution of LUN_RESETs and Preempt and Aborts. Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list, because it turns out the original patch fixed a bug that was not mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second LUN_RESET and wait on it. Then the second reset will run core_tmr_drain_tmr_list and see the first reset and wait on it resulting in a deadlock. Fixes: 51ec502a3266 ("target: Delete tmr from list before processing") Signed-off-by: Mike Christie Link: https://lore.kernel.org/r/20230319015620.96006-8-michael.christie@oracle.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: target: iscsit: isert: Alloc per conn cmd counter

2023-05-11T14:17:14+00:00

[ Upstream commit 6d256bee602b131bd4fbc92863b6a1210bcf6325 ] This has iscsit allocate a per conn cmd counter and converts iscsit/isert to use it instead of the per session one. Signed-off-by: Mike Christie Link: https://lore.kernel.org/r/20230319015620.96006-5-michael.christie@oracle.com Signed-off-by: Martin K. Petersen Stable-dep-of: 395cee83d02d ("scsi: target: iscsit: Stop/wait on cmds during conn close") Signed-off-by: Sasha Levin

scsi: target: Pass in cmd counter to use during cmd setup

2023-05-11T14:17:13+00:00

[ Upstream commit 8e288be8606ad87c1726618eacfb8fbd3ab4b806 ] Allow target_get_sess_cmd() users to pass in the cmd counter they want to use. Right now we pass in the session's cmd counter but in a subsequent commit iSCSI will switch from per session to per conn. Signed-off-by: Mike Christie Link: https://lore.kernel.org/r/20230319015620.96006-4-michael.christie@oracle.com Signed-off-by: Martin K. Petersen Stable-dep-of: 395cee83d02d ("scsi: target: iscsit: Stop/wait on cmds during conn close") Signed-off-by: Sasha Levin

scsi: target: Move cmd counter allocation

2023-05-11T14:17:13+00:00

[ Upstream commit 4edba7e4a8f39112398d3cda94128a8e13a7d527 ] iSCSI needs to allocate its cmd counter per connection for MCS support where we need to stop and wait on commands running on a connection instead of per session. This moves the cmd counter allocation to target_setup_session() which is used by drivers that need the stop+wait behavior per session. xcopy doesn't need stop+wait at all, so we will be OK moving the cmd counter allocation outside of transport_init_session(). Signed-off-by: Mike Christie Link: https://lore.kernel.org/r/20230319015620.96006-3-michael.christie@oracle.com Signed-off-by: Martin K. Petersen Stable-dep-of: 395cee83d02d ("scsi: target: iscsit: Stop/wait on cmds during conn close") Signed-off-by: Sasha Levin

scsi: target: Move sess cmd counter to new struct

2023-05-11T14:17:13+00:00

[ Upstream commit becd9be6069e7b183c084f460f0eb363e43cc487 ] iSCSI needs to wait on outstanding commands like how SRP and the FC/FCoE drivers do. It can't use target_stop_session() because for MCS support we can't stop the entire session during recovery because if other connections are OK then we want to be able to continue to execute I/O on them. Move the per session cmd counters to a new struct so iSCSI can allocate them per connection. The xcopy code can also just not allocate in the future since it doesn't need to track commands. Signed-off-by: Mike Christie Link: https://lore.kernel.org/r/20230319015620.96006-2-michael.christie@oracle.com Reviewed-by: Maurizio Lombardi Signed-off-by: Martin K. Petersen Stable-dep-of: 395cee83d02d ("scsi: target: iscsit: Stop/wait on cmds during conn close") Signed-off-by: Sasha Levin

scsi: target: core: Send max transfer length in blocks

2022-11-24T02:16:19+00:00

A MAXIMUM TRANSFER LENGTH value indicates the maximum transfer length in logical blocks that the device server accepts for a single command. Fix function sending the length in sectors instead of blocks. This patch also removes the special casing for fileio in block_size_store since this logic in now unified in spc_emulate_evpd_b0() for all backends. Reviewed-by: Konstantin Shelekhin Reviewed-by: Dmitriy Bogdanov Signed-off-by: Anastasia Kovaleva Link: https://lore.kernel.org/r/20221114102500.88892-2-a.kovaleva@yadro.com Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen

scsi: target: core: Dynamically set DPO and FUA in usage_bits

2022-10-27T01:47:24+00:00

libiscsi tests check the support of DPO & FUA bits in usage bits of RSOC response. This patch adds support for dynamic usage bits for each opcode. Set support of DPO & FUA bits in usage_bits of RSOC response depending on support DPOFUA in the backstore device. Reviewed-by: Roman Bolshakov Reviewed-by: Konstantin Shelekhin Signed-off-by: Dmitry Bogdanov Link: https://lore.kernel.org/r/20220906103421.22348-7-d.bogdanov@yadro.com Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen

scsi: target: core: Add emulate_rsoc attribute

2022-10-27T01:44:32+00:00

Allow support for RSOC to be turned off via the emulate_rsoc attibute. This is just for testing purposes. Reviewed-by: Roman Bolshakov Signed-off-by: Dmitry Bogdanov Link: https://lore.kernel.org/r/20220906103421.22348-5-d.bogdanov@yadro.com Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen

scsi: target: core: Dynamic opcode support in RSOC

2022-10-27T01:44:32+00:00

Report supported opcodes depending on a dynamic device configuration. Reviewed-by: Roman Bolshakov Signed-off-by: Dmitry Bogdanov Link: https://lore.kernel.org/r/20220906103421.22348-4-d.bogdanov@yadro.com Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen

scsi: target: core: Add support for RSOC command

2022-10-27T01:44:32+00:00

Add support for REPORT SUPPORTED OPERATION CODES command according to SPC4. Reviewed-by: Roman Bolshakov Signed-off-by: Dmitry Bogdanov Link: https://lore.kernel.org/r/20220906103421.22348-2-d.bogdanov@yadro.com Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen