1. 27 Jul, 2022 2 commits
  2. 14 Jul, 2022 5 commits
  3. 07 Jul, 2022 1 commit
  4. 28 Jun, 2022 1 commit
  5. 17 Jun, 2022 6 commits
    • Tyrel Datwyler's avatar
      scsi: ibmvfc: Store vhost pointer during subcrq allocation · aeaadcde
      Tyrel Datwyler authored
      Currently the back pointer from a queue to the vhost adapter isn't set
      until after subcrq interrupt registration. The value is available when a
      queue is first allocated and can/should be also set for primary and async
      queues as well as subcrqs.
      
      This fixes a crash observed during kexec/kdump on Power 9 with legacy XICS
      interrupt controller where a pending subcrq interrupt from the previous
      kernel can be replayed immediately upon IRQ registration resulting in
      dereference of a garbage backpointer in ibmvfc_interrupt_scsi().
      
      Kernel attempted to read user page (58) - exploit attempt? (uid: 0)
      BUG: Kernel NULL pointer dereference on read at 0x00000058
      Faulting instruction address: 0xc008000003216a08
      Oops: Kernel access of bad area, sig: 11 [#1]
      ...
      NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc]
      LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270
      Call Trace:
      [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable)
      [c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270
      [c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188
      [c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310
      [c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80
      [c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0
      [c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130
      [c000000014622f60] [0000000020000000] 0x20000000
      [c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0
      [c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0
      [c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170
      [c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0
      [c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0
      [c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230
      [c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc]
      [c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc]
      [c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc]
      [c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc]
      [c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc]
      
      Link: https://lore.kernel.org/r/20220616191126.1281259-2-tyreld@linux.ibm.com
      Fixes: 3034ebe2 ("scsi: ibmvfc: Add alloc/dealloc routines for SCSI Sub-CRQ Channels")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      aeaadcde
    • Tyrel Datwyler's avatar
      scsi: ibmvfc: Allocate/free queue resource only during probe/remove · 72ea7fe0
      Tyrel Datwyler authored
      Currently, the sub-queues and event pool resources are allocated/freed for
      every CRQ connection event such as reset and LPM. This exposes the driver
      to a couple issues. First the inefficiency of freeing and reallocating
      memory that can simply be resued after being sanitized. Further, a system
      under memory pressue runs the risk of allocation failures that could result
      in a crippled driver. Finally, there is a race window where command
      submission/compeletion can try to pull/return elements from/to an event
      pool that is being deleted or already has been deleted due to the lack of
      host state around freeing/allocating resources. The following is an example
      of list corruption following a live partition migration (LPM):
      
      Oops: Exception in kernel mode, sig: 5 [#1]
      LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
      Modules linked in: vfat fat isofs cdrom ext4 mbcache jbd2 nft_counter nft_compat nf_tables nfnetlink rpadlpar_io rpaphp xsk_diag nfsv3 nfs_acl nfs lockd grace fscache netfs rfkill bonding tls sunrpc pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth vmx_crypto dm_multipath dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
      CPU: 0 PID: 2108 Comm: ibmvfc_0 Kdump: loaded Not tainted 5.14.0-70.9.1.el9_0.ppc64le #1
      NIP: c0000000007c4bb0 LR: c0000000007c4bac CTR: 00000000005b9a10
      REGS: c00000025c10b760 TRAP: 0700  Not tainted (5.14.0-70.9.1.el9_0.ppc64le)
      MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 2800028f XER: 0000000f
      CFAR: c0000000001f55bc IRQMASK: 0
              GPR00: c0000000007c4bac c00000025c10ba00 c000000002a47c00 000000000000004e
              GPR04: c0000031e3006f88 c0000031e308bd00 c00000025c10b768 0000000000000027
              GPR08: 0000000000000000 c0000031e3009dc0 00000031e0eb0000 0000000000000000
              GPR12: c0000031e2ffffa8 c000000002dd0000 c000000000187108 c00000020fcee2c0
              GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
              GPR20: 0000000000000000 0000000000000000 0000000000000000 c008000002f81300
              GPR24: 5deadbeef0000100 5deadbeef0000122 c000000263ba6910 c00000024cc88000
              GPR28: 000000000000003c c0000002430a0000 c0000002430ac300 000000000000c300
      NIP [c0000000007c4bb0] __list_del_entry_valid+0x90/0x100
      LR [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100
      Call Trace:
      [c00000025c10ba00] [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100 (unreliable)
      [c00000025c10ba60] [c008000002f42284] ibmvfc_free_queue+0xec/0x210 [ibmvfc]
      [c00000025c10bb10] [c008000002f4246c] ibmvfc_deregister_scsi_channel+0xc4/0x160 [ibmvfc]
      [c00000025c10bba0] [c008000002f42580] ibmvfc_release_sub_crqs+0x78/0x130 [ibmvfc]
      [c00000025c10bc20] [c008000002f4f6cc] ibmvfc_do_work+0x5c4/0xc70 [ibmvfc]
      [c00000025c10bce0] [c008000002f4fdec] ibmvfc_work+0x74/0x1e8 [ibmvfc]
      [c00000025c10bda0] [c0000000001872b8] kthread+0x1b8/0x1c0
      [c00000025c10be10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64
      Instruction dump:
      40820034 38600001 38210060 4e800020 7c0802a6 7c641b78 3c62fe7a 7d254b78
      3863b590 f8010070 4ba309cd 60000000 <0fe00000> 7c0802a6 3c62fe7a 3863b640
      ---[ end trace 11a2b65a92f8b66c ]---
      ibmvfc 30000003: Send warning. Receive queue closed, will retry.
      
      Add registration/deregistration helpers that are called instead during
      connection resets to sanitize and reconfigure the queues.
      
      Link: https://lore.kernel.org/r/20220616191126.1281259-3-tyreld@linux.ibm.com
      Fixes: 3034ebe2 ("scsi: ibmvfc: Add alloc/dealloc routines for SCSI Sub-CRQ Channels")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      72ea7fe0
    • Saurabh Sengar's avatar
      scsi: storvsc: Correct reporting of Hyper-V I/O size limits · 1d3e0980
      Saurabh Sengar authored
      Current code is based on the idea that the max number of SGL entries
      also determines the max size of an I/O request.  While this idea was
      true in older versions of the storvsc driver when SGL entry length
      was limited to 4 Kbytes, commit 3d9c3dcc ("scsi: storvsc: Enable
      scatterlist entry lengths > 4Kbytes") removed that limitation. It's
      now theoretically possible for the block layer to send requests that
      exceed the maximum size supported by Hyper-V. This problem doesn't
      currently happen in practice because the block layer defaults to a
      512 Kbyte maximum, while Hyper-V in Azure supports 2 Mbyte I/O sizes.
      But some future configuration of Hyper-V could have a smaller max I/O
      size, and the block layer could exceed that max.
      
      Fix this by correctly setting max_sectors as well as sg_tablesize to
      reflect the maximum I/O size that Hyper-V reports. While allowing
      I/O sizes larger than the block layer default of 512 Kbytes doesn’t
      provide any noticeable performance benefit in the tests we ran, it's
      still appropriate to report the correct underlying Hyper-V capabilities
      to the Linux block layer.
      
      Also tweak the virt_boundary_mask to reflect that the required
      alignment derives from Hyper-V communication using a 4 Kbyte page size,
      and not on the guest page size, which might be bigger (eg. ARM64).
      
      Link: https://lore.kernel.org/r/1655190355-28722-1-git-send-email-ssengar@linux.microsoft.com
      Fixes: 3d9c3dcc ("scsi: storvsc: Enable scatter list entry lengths > 4Kbytes")
      Reviewed-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: default avatarSaurabh Sengar <ssengar@linux.microsoft.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      1d3e0980
    • Bart Van Assche's avatar
      scsi: ufs: Fix a race between the interrupt handler and the reset handler · 2acd76e7
      Bart Van Assche authored
      Prevent that both the interrupt handler and the reset handler try to
      complete a request at the same time. This patch is the result of an
      analysis of the following crash:
      
      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           OE     5.10.107-android13-4-00051-g1e48e8970cca-ab8664745 #1
      pc : ufshcd_release_scsi_cmd+0x30/0x46c
      lr : __ufshcd_transfer_req_compl+0x4fc/0x9c0
      Call trace:
       ufshcd_release_scsi_cmd+0x30/0x46c
       __ufshcd_transfer_req_compl+0x4fc/0x9c0
       ufshcd_poll+0xf0/0x208
       ufshcd_sl_intr+0xb8/0xf0
       ufshcd_intr+0x168/0x2f4
       __handle_irq_event_percpu+0xa0/0x30c
       handle_irq_event+0x84/0x178
       handle_fasteoi_irq+0x150/0x2e8
       __handle_domain_irq+0x114/0x1e4
       gic_handle_irq.31846+0x58/0x300
       el1_irq+0xe4/0x1c0
       cpuidle_enter_state+0x3ac/0x8c4
       do_idle+0x2fc/0x55c
       cpu_startup_entry+0x84/0x90
       kernel_init+0x0/0x310
       start_kernel+0x0/0x608
       start_kernel+0x4ec/0x608
      
      Link: https://lore.kernel.org/r/20220613214442.212466-4-bvanassche@acm.orgReviewed-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      2acd76e7
    • Bart Van Assche's avatar
      scsi: ufs: Support clearing multiple commands at once · d1a76446
      Bart Van Assche authored
      Modify ufshcd_clear_cmd() such that it supports clearing multiple commands
      at once instead of one command at a time. This change will be used in a
      later patch to reduce the time spent in the reset handler.
      
      Link: https://lore.kernel.org/r/20220613214442.212466-3-bvanassche@acm.orgReviewed-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      d1a76446
    • Bart Van Assche's avatar
      scsi: ufs: Simplify ufshcd_clear_cmd() · da8badd7
      Bart Van Assche authored
      Remove the local variable 'err'. This patch does not change any
      functionality.
      
      Link: https://lore.kernel.org/r/20220613214442.212466-2-bvanassche@acm.orgReviewed-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      da8badd7
  6. 14 Jun, 2022 1 commit
  7. 10 Jun, 2022 1 commit
  8. 08 Jun, 2022 14 commits
  9. 06 Jun, 2022 3 commits
  10. 05 Jun, 2022 6 commits