scsi: ufs: Fix hardware race conditions while aborting a command
authorSujit Reddy Thumma <sthumma@codeaurora.org>
Mon, 26 May 2014 05:29:13 +0000 (10:59 +0530)
committerChristoph Hellwig <hch@lst.de>
Wed, 28 May 2014 10:25:13 +0000 (12:25 +0200)
commitf20810d8d0bbe70dc6bb526213c31171f7e54751
tree138e6bf419064b20da29634de401433617ebf1de
parente293313262d3c780632f7888878c982fa0a9bf7e
scsi: ufs: Fix hardware race conditions while aborting a command

There is a possible race condition in the hardware when the abort
command is issued to terminate the ongoing SCSI command as described
below:

- A bit in the door-bell register is set in the controller for a
  new SCSI command.
- In some rare situations, before controller get a chance to issue
  the command to the device, the software issued an abort command.
- If the device recieves abort command first then it returns success
  because the command itself is not present.
- Now if the controller commits the command to device it will be
  processed.
- Software thinks that command is aborted and proceed while still
  the device is processing it.
- The software, controller and device may go out of sync because of
  this race condition.

To avoid this, query task presence in the device before sending abort
task command so that after the abort operation, the command is guaranteed
to be non-existent in both controller and the device.

Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Reviewed-by: Yaniv Gardi <ygardi@codeaurora.org>
Tested-by: Dolev Raviv <draviv@codeaurora.org>
Acked-by: Vinayak Holikatti <vinholikatti@gmail.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
drivers/scsi/ufs/ufshcd.c