• Jason Yan's avatar
    scsi: libsas: defer ata device eh commands to libata · 318aaf34
    Jason Yan authored
    When ata device doing EH, some commands still attached with tasks are
    not passed to libata when abort failed or recover failed, so libata did
    not handle these commands. After these commands done, sas task is freed,
    but ata qc is not freed. This will cause ata qc leak and trigger a
    warning like below:
    
    WARNING: CPU: 0 PID: 28512 at drivers/ata/libata-eh.c:4037
    ata_eh_finish+0xb4/0xcc
    CPU: 0 PID: 28512 Comm: kworker/u32:2 Tainted: G     W  OE 4.14.0#1
    ......
    Call trace:
    [<ffff0000088b7bd0>] ata_eh_finish+0xb4/0xcc
    [<ffff0000088b8420>] ata_do_eh+0xc4/0xd8
    [<ffff0000088b8478>] ata_std_error_handler+0x44/0x8c
    [<ffff0000088b8068>] ata_scsi_port_error_handler+0x480/0x694
    [<ffff000008875fc4>] async_sas_ata_eh+0x4c/0x80
    [<ffff0000080f6be8>] async_run_entry_fn+0x4c/0x170
    [<ffff0000080ebd70>] process_one_work+0x144/0x390
    [<ffff0000080ec100>] worker_thread+0x144/0x418
    [<ffff0000080f2c98>] kthread+0x10c/0x138
    [<ffff0000080855dc>] ret_from_fork+0x10/0x18
    
    If ata qc leaked too many, ata tag allocation will fail and io blocked
    for ever.
    
    As suggested by Dan Williams, defer ata device commands to libata and
    merge sas_eh_finish_cmd() with sas_eh_defer_cmd(). libata will handle
    ata qcs correctly after this.
    Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
    CC: Xiaofei Tan <tanxiaofei@huawei.com>
    CC: John Garry <john.garry@huawei.com>
    CC: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
    Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
    318aaf34
sas_scsi_host.c 24.7 KB