On 7/11/21 5:29 AM, Avri Altman wrote:
The following unlikely races can be triggered by the completion path
(ufshcd_trc_handler()):
- After the UTRLCNR register has been read from interrupt context and
before it is cleared, the UFS error handler reads the UTRLCNR register.
Hold the SCSI host lock until the UTRLCNR register has been cleared to
prevent that this register is accessed from another CPU before it has
been cleared.
- After the doorbell register has been read and before outstanding_reqs
is cleared, the error handler reads the doorbell register. This can also
result in double completions. Fix this by clearing outstanding_reqs
before calling ufshcd_transfer_req_compl().
Due to this change ufshcd_trc_handler() no longer updates
outstanding_reqs
atomically. Hence protect all other outstanding_reqs changes with the SCSI
host lock.
But isn't the whole point of REG_UTP_TRANSFER_REQ_LIST_COMPL is to eliminate the host lock
As a source of contention?
How about avoiding contention by introducing a new spinlock to protect
hba->outstanding_reqs?
This patch is a performance improvement because it reduces the number of
atomic operations in the hot path (test_and_clear_bit()).
Both Can & Stanley reported a performance improvement of RR with "Optimize host lock..".
Can those short numerical studies can be repeated with this patch?
I will measure the performance impact of this patch for rq_affinity=2 as
soon as I have the time. As you may know we are close to an internal
deadline.
Thanks,
Bart.
