[ 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 <michael.christie@oracle.com>
Link: https://lore.kernel.org/r/20230319015620.96006-8-michael.christie@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

Pull SCSI updates from James Bottomley:
 "Updates to the usual drivers (target, ufs, smartpqi, lpfc).

  There are some core changes, mostly around reworking some of our user
  context assumptions in device put and moving some code around.

  The remaining updates are bug fixes and minor changes"

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (138 commits)
  scsi: sg: Fix get_user() in call sg_scsi_ioctl()
  scsi: megaraid_sas: Fix some spelling mistakes in comment
  scsi: core: Use SCSI_SCAN_INITIAL in do_scsi_scan_host()
  scsi: core: Use SCSI_SCAN_RESCAN in __scsi_add_device()
  scsi: ufs: ufs-mediatek: Remove unnecessary return code
  scsi: ufs: core: Fix the polling implementation
  scsi: libsas: Do not export sas_ata_wait_after_reset()
  scsi: hisi_sas: Fix SATA devices missing issue during I_T nexus reset
  scsi: libsas: Add smp_ata_check_ready_type()
  scsi: Revert "scsi: hisi_sas: Don't send bcast events from HW during nexus HA reset"
  scsi: Revert "scsi: hisi_sas: Drain bcast events in hisi_sas_rescan_topology()"
  scsi: ufs: ufs-mediatek: Modify the return value
  scsi: ufs: ufs-mediatek: Remove unneeded code
  scsi: device_handler: alua: Call scsi_device_put() from non-atomic context
  scsi: device_handler: alua: Revert "Move a scsi_device_put() call out of alua_check_vpd()"
  scsi: snic: Fix possible UAF in snic_tgt_create()
  scsi: qla2xxx: Initialize vha->unknown_atio_[list, work] for NPIV hosts
  scsi: qla2xxx: Remove duplicate of vha->iocb_work initialization
  scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails
  scsi: sd: Use 16-byte SYNCHRONIZE CACHE on ZBC devices
  ...

Allow support for RSOC to be turned off via the emulate_rsoc attibute.
This is just for testing purposes.

Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://lore.kernel.org/r/20220906103421.22348-5-d.bogdanov@yadro.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Allocate UNIT ATTENTION "BUS DEVICE RESET OCCURRED" on all LUNs on all
target ports of the device upon reception of TMF LUN RESET.

This change passes libiscsi test SCSI.MultipathIO.Reset.

Link: https://lore.kernel.org/r/20220913163602.20597-1-d.bogdanov@yadro.com
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

se_lun and se_lun_acl are immutable pointers of struct se_dev_entry.
Remove RCU usage for access to those pointers.

Link: https://lore.kernel.org/r/20220727214125.19647-3-d.bogdanov@yadro.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Under huge load there is a possibility of race condition in updating
se_dev_entry object in ACL removal procedure:

 NIP [c0080000154093d0] transport_lookup_cmd_lun+0x1f8/0x3d0 [target_core_mod]
 LR [c00800001542ab34] target_submit_cmd_map_sgls+0x11c/0x300 [target_core_mod]
 Call Trace:
   target_submit_cmd_map_sgls+0x11c/0x300 [target_core_mod]
   target_submit_cmd+0x44/0x60 [target_core_mod]
   tcm_qla2xxx_handle_cmd+0x88/0xe0 [tcm_qla2xxx]
   qlt_do_work+0x2e4/0x3d0 [qla2xxx]
   process_one_work+0x298/0x5c

Despite usage of RCU primitives with deve->se_lun pointer, it has not
become dereference-safe because deve->se_lun is updated and not
synchronized with a reader. That change might be in a release function
called by synchronize_rcu(). But, in fact, there is no point in setting
that pointer to NULL for deleting deve. All access to deve->se_lun is
already under rcu_read_lock. And either deve->se_lun is always valid or
deve is not valid itself and will not be found in the list_for_*.  The same
applicable for deve->se_lun_acl too.  So a better solution is to remove
that NULLing.

Link: https://lore.kernel.org/r/20220727214125.19647-2-d.bogdanov@yadro.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Add a callout to configure a backend's UNMAP settings. This will be used to
allow userspace to configure UNMAP after the initial device setup, similar
to how we can set up the other attributes post device configuration.

Link: https://lore.kernel.org/r/20220628200230.15052-3-michael.christie@oracle.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Abstract away implementation details from file systems by providing a
block_device based helper to retrieve the discard granularity.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> [drbd]
Acked-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Acked-by: David Sterba <dsterba@suse.com> [btrfs]
Link: https://lore.kernel.org/r/20220415045258.199825-26-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Just use a non-zero max_discard_sectors as an indicator for discard
support, similar to what is done for write zeroes.

The only places where needs special attention is the RAID5 driver,
which must clear discard support for security reasons by default,
even if the default stacking rules would allow for it.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> [drbd]
Acked-by: Jan Höppner <hoeppner@linux.ibm.com> [s390]
Acked-by: Coly Li <colyli@suse.de> [bcache]
Acked-by: David Sterba <dsterba@suse.com> [btrfs]
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Link: https://lore.kernel.org/r/20220415045258.199825-25-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Add a helper to query the number of sectors support per each discard bio
based on the block device and use this helper to stop various places from
poking into the request_queue to see if discard is supported and if so how
much.  This mirrors what is done e.g. for write zeroes as well.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> [drbd]
Acked-by: Coly Li <colyli@suse.de> [bcache]
Acked-by: David Sterba <dsterba@suse.com> [btrfs]
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Link: https://lore.kernel.org/r/20220415045258.199825-24-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>