lkml.org 
[lkml]   [2020]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 5.5 244/257] scsi: mpt3sas: Fix kernel panic observed on soft HBA unplug
    Date
    From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>

    commit cc41f11a21a51d6869d71e525a7264c748d7c0d7 upstream.

    Generic protection fault type kernel panic is observed when user performs
    soft (ordered) HBA unplug operation while IOs are running on drives
    connected to HBA.

    When user performs ordered HBA removal operation, the kernel calls PCI
    device's .remove() call back function where driver is flushing out all the
    outstanding SCSI IO commands with DID_NO_CONNECT host byte and also unmaps
    sg buffers allocated for these IO commands.

    However, in the ordered HBA removal case (unlike of real HBA hot removal),
    HBA device is still alive and hence HBA hardware is performing the DMA
    operations to those buffers on the system memory which are already unmapped
    while flushing out the outstanding SCSI IO commands and this leads to
    kernel panic.

    Don't flush out the outstanding IOs from .remove() path in case of ordered
    removal since HBA will be still alive in this case and it can complete the
    outstanding IOs. Flush out the outstanding IOs only in case of 'physical
    HBA hot unplug' where there won't be any communication with the HBA.

    During shutdown also it is possible that HBA hardware can perform DMA
    operations on those outstanding IO buffers which are completed with
    DID_NO_CONNECT by the driver from .shutdown(). So same above fix is applied
    in shutdown path as well.

    It is safe to drop the outstanding commands when HBA is inaccessible such
    as when permanent PCI failure happens, when HBA is in non-operational
    state, or when someone does a real HBA hot unplug operation. Since driver
    knows that HBA is inaccessible during these cases, it is safe to drop the
    outstanding commands instead of waiting for SCSI error recovery to kick in
    and clear these outstanding commands.

    Link: https://lore.kernel.org/r/1585302763-23007-1-git-send-email-sreekanth.reddy@broadcom.com
    Fixes: c666d3be99c0 ("scsi: mpt3sas: wait for and flush running commands on shutdown/unload")
    Cc: stable@vger.kernel.org #v4.14.174+
    Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


    ---
    drivers/scsi/mpt3sas/mpt3sas_scsih.c | 8 ++++----
    1 file changed, 4 insertions(+), 4 deletions(-)

    --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
    +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
    @@ -9747,8 +9747,8 @@ static void scsih_remove(struct pci_dev

    ioc->remove_host = 1;

    - mpt3sas_wait_for_commands_to_complete(ioc);
    - _scsih_flush_running_cmds(ioc);
    + if (!pci_device_is_present(pdev))
    + _scsih_flush_running_cmds(ioc);

    _scsih_fw_event_cleanup_queue(ioc);

    @@ -9831,8 +9831,8 @@ scsih_shutdown(struct pci_dev *pdev)

    ioc->remove_host = 1;

    - mpt3sas_wait_for_commands_to_complete(ioc);
    - _scsih_flush_running_cmds(ioc);
    + if (!pci_device_is_present(pdev))
    + _scsih_flush_running_cmds(ioc);

    _scsih_fw_event_cleanup_queue(ioc);


    \
     
     \ /
      Last update: 2020-04-16 17:40    [W:4.066 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site