diff options
| author | Viswas G <Viswas.G@microchip.com> | 2020-11-02 22:25:26 +0530 |
|---|---|---|
| committer | Martin K. Petersen <martin.petersen@oracle.com> | 2020-11-04 22:55:38 -0500 |
| commit | 4a2efd4b89fcaa6e9a7b4ce49a441afaacba00ea (patch) | |
| tree | d109038e31a56138f7b1c0161f468b536442086e /tools/perf/scripts/python/export-to-postgresql.py | |
| parent | 7640e1eb8c5de33dafa6c68fd4389214ff9ec1f9 (diff) | |
| download | linux-4a2efd4b89fcaa6e9a7b4ce49a441afaacba00ea.tar.gz linux-4a2efd4b89fcaa6e9a7b4ce49a441afaacba00ea.zip | |
scsi: pm80xx: Make running_req atomic
Incorrect value of the running_req was causing the driver unload to be
stuck during the SAS lldd_dev_gone notification handling. During SATA I/O
completion, for some error status values, the driver schedules the event
handler and running_req is decremented from that. However, there are some
other error status values (like IO_DS_IN_RECOVERY,
IO_XFER_ERR_LAST_PIO_DATAIN_CRC_ERR) where the I/O has already been
completed by fw/driver so running_req is not decremented.
Also during NCQ error handling, driver itself will initiate READ_LOG_EXT
and ABORT_ALL. When libsas/libata initiate READ_LOG_EXT (0x2F), driver
increments running_req. This will be completed by the driver in
pm80xx_chip_sata_req(), but running_req was not decremented.
Link: https://lore.kernel.org/r/20201102165528.26510-3-Viswas.G@microchip.com.com
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions