Re: [PATCH v1 2/3] scsi: ufs: Optimize host lock on transfer requests send/compl paths

[Bart Van Assche]

On 5/24/21 1:36 AM, Can Guo wrote:
> Current UFS IRQ handler is completely wrapped by host lock, and because
> ufshcd_send_command() is also protected by host lock, when IRQ handler
> fires, not only the CPU running the IRQ handler cannot send new requests,
> the rest CPUs can neither. Move the host lock wrapping the IRQ handler into
> specific branches, i.e., ufshcd_uic_cmd_compl(), ufshcd_check_errors(),
> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to further
> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host lock is
> no longer required to call __ufshcd_transfer_req_compl(). As per test, the
> optimization can bring considerable gain to random read/write performance.

Hi Can,

Since this patch has been applied on the AOSP kernel we see 100%
reproducible lockups appearing on multiple test setups. Examples of call
traces:

blk_execute_rq()
__scsi_execute()
sd_sync_cache()
sd_suspend_common()
sd_suspend_system()
scsi_bus_suspend()
__device_suspend()

blk_execute_rq()
__scsi_execute()
ufshcd_clear_ua_wlun()
ufshcd_err_handling_unprepare()
ufshcd_err_handler()
process_one_work()

Reverting this patch and the next patch from this series solved the
lockups. Do you prefer to revert this patch or do you perhaps want us to
test a potential fix?

Thanks,

Bart.