The first patch is already in Jammy

commit 06adda263bd3776b019f282318efe18dd5bfa173
Author: Karan Tilak Kumar <karti...@cisco.com>
Date:   Thu Jul 27 12:39:19 2023 -0700

    scsi: fnic: Replace return codes in fnic_clean_pending_aborts()
    
    BugLink: https://bugs.launchpad.net/bugs/2038382
    
    commit 5a43b07a87835660f91d88a4db11abfea8c523b7 upstream.
    
    fnic_clean_pending_aborts() was returning a non-zero value irrespective of
    failure or success.  This caused the caller of this function to assume that
    the device reset had failed, even though it would succeed in most cases. As
    a consequence, a successful device reset would escalate to host reset.
    
    Reviewed-by: Sesidhar Baddela <sebad...@cisco.com>
    Tested-by: Karan Tilak Kumar <karti...@cisco.com>
    Signed-off-by: Karan Tilak Kumar <karti...@cisco.com>
    Link: https://lore.kernel.org/r/20230727193919.2519-1-karti...@cisco.com
    Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
    Signed-off-by: Kamal Mostafa <ka...@canonical.com>
    Signed-off-by: Stefan Bader <stefan.ba...@canonical.com>

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2036777

Title:
  [SRU] Fnic driver on needs to be updated to 1.6.0.57 on Jammy

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Jammy:
  New
Status in linux source package in Lunar:
  New
Status in linux source package in Mantic:
  Incomplete

Bug description:
  [Impact]

  fnic_clean_pending_aborts() was returning a non-zero value
  irrespective of failure or success.
  This caused the caller of this function to assume that the
  device reset had failed, even though it would succeed in
  most cases. As a consequence, a successful device reset
  would escalate to host reset.

  sgreset is issued with a scsi command pointer.
  The device reset code assumes that it was issued
  on a hardware queue, and calls block multiqueue
  layer. However, the assumption is broken, and
  there is no hardware queue associated with the
  sgreset, and this leads to a crash due to a
  null pointer exception.

  [Fix]
  Fix the code to use the max_tag_id as a tag
  which does not overlap with the other tags
  issued by mid layer.

  Below are the kernel patches which picked for the newer version of
  fins driver.

  https://lore.kernel.org/lkml/20230727193919.2519-1-karti...@cisco.com/

  https://lore.kernel.org/lkml/20230817182146.229059-1-karti...@cisco.com/

  https://lore.kernel.org/lkml/20230919182436.6895-1-karti...@cisco.com/

  [Test Plan]
  Tested by running FC traffic for a few minutes,
  and by issuing sgreset on the device in parallel.
  Without the fix, the crash is observed right away.
  With this fix, no crash is observed.

  sg_reset performs a device reset/lun reset on a lun.
  Since it is issued by the user, it does not come into the
  driver with a tag or a queue id.
  Fix the fnic driver to create an io_req and use a scsi command tag.
  Fix the ITMF path to special case the sg_reset response.

  [ Where problems could occur ]

  [ Other Info ]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2036777/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to