scsi: ufs: Fix the SCSI abort handler

Make the following changes in ufshcd_abort():

 - Return FAILED instead of SUCCESS if the abort handler notices that a
   SCSI command has already been completed. Returning SUCCESS in this case
   triggers a use-after-free and may trigger a kernel crash.

 - Fix the code for aborting SCSI commands submitted to a WLUN.

The current approach for aborting SCSI commands that have been submitted to
a WLUN and that timed out is as follows:

 - Report to the SCSI core that the command has completed successfully.
   Let the block layer free any data buffers associated with the command.

 - Mark the command as outstanding in 'outstanding_reqs'.

 - If the block layer tries to reuse the tag associated with the aborted
   command, busy-wait until the tag is freed.

This approach can result in:

 - Memory corruption if the controller accesses the data buffer after the
   block layer has freed the associated data buffers.

 - A race condition if ufshcd_queuecommand() or ufshcd_exec_dev_cmd()
   checks the bit that corresponds to an aborted command in
   'outstanding_reqs' after it has been cleared and before it is reset.

 - High energy consumption if ufshcd_queuecommand() repeatedly returns
   SCSI_MLQUEUE_HOST_BUSY.

Fix this by reporting to the SCSI error handler that aborting a SCSI
command failed if the SCSI command was submitted to a WLUN.

Link: https://lore.kernel.org/r/20210722033439.26550-15-bvanassche@acm.org
Fixes: 7a7e66c65d41 ("scsi: ufs: Fix a race condition between ufshcd_abort() and eh_work()")
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Stanley Chu <stanley.chu@mediatek.com>
Cc: Can Guo <cang@codeaurora.org>
Cc: Asutosh Das <asutoshd@codeaurora.org>
Cc: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

0 files changed, 0 insertions, 0 deletions