linux-stable.git/drivers/infiniband, branch v5.5

Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2020-01-26T18:39:09+00:00

Pull SCSI fixes from James Bottomley:
 "Two last minute fixes, both in drivers.

  The fnic one is a highly unlikely condition, but the RDMA one is a
  recently introduced regression that causes a kernel warning to trigger
  in every RDMA logon, which would be unsightly if it got into the final
  release"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: RDMA/isert: Fix a recently introduced regression related to logout
  scsi: fnic: do not queue commands during fwreset

scsi: RDMA/isert: Fix a recently introduced regression related to logout

2020-01-21T05:24:46+00:00

iscsit_close_connection() calls isert_wait_conn(). Due to commit
e9d3009cb936 both functions call target_wait_for_sess_cmds() although that
last function should be called only once. Fix this by removing the
target_wait_for_sess_cmds() call from isert_wait_conn() and by only calling
isert_wait_conn() after target_wait_for_sess_cmds().

Fixes: e9d3009cb936 ("scsi: target: iscsi: Wait for all commands to finish before freeing a session").
Link: https://lore.kernel.org/r/20200116044737.19507-1-bvanassche@acm.org
Reported-by: Rahul Kundu 
Signed-off-by: Bart Van Assche 
Tested-by: Mike Marciniszyn 
Acked-by: Sagi Grimberg 
Signed-off-by: Martin K. Petersen

i40iw: Remove setting of VMA private data and use rdma_user_mmap_io

2020-01-07T19:07:37+00:00

vm_ops is now initialized in ib_uverbs_mmap() with the recent rdma mmap
API changes. Earlier it was done in rdma_umap_priv_init() which would not
be called unless a driver called rdma_user_mmap_io() in its mmap.

i40iw does not use the rdma_user_mmap_io API but sets the vma's
vm_private_data to a driver object. This now conflicts with the vm_op
rdma_umap_close as priv pointer points to the i40iw driver object instead
of the private data setup by core when rdma_user_mmap_io is called.  This
leads to a crash in rdma_umap_close with a mmap put being called when it
should not have.

Remove the redundant setting of the vma private_data in i40iw as it is not
used. Also move i40iw over to use the rdma_user_mmap_io API. This gives
the extra protection of having the mappings zapped when the context is
detsroyed.

  BUG: unable to handle page fault for address: 0000000100000001
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0002) - not-present page
  PGD 0 P4D 0
  Oops: 0002 [#1] SMP PTI
  CPU: 6 PID: 9528 Comm: rping Kdump: loaded Not tainted 5.5.0-rc4+ #117
  Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Q87M-D2H, BIOS F7 01/17/2014
  RIP: 0010:rdma_user_mmap_entry_put+0xa/0x30 [ib_core]
  RSP: 0018:ffffb340c04c7c38 EFLAGS: 00010202
  RAX: 00000000ffffffff RBX: ffff9308e7be2a00 RCX: 000000000000cec0
  RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000100000001
  RBP: ffff9308dc7641f0 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000001 R11: ffffffff8d4414d8 R12: ffff93075182c780
  R13: 0000000000000001 R14: ffff93075182d2a8 R15: ffff9308e2ddc840
  FS:  0000000000000000(0000) GS:ffff9308fdc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000100000001 CR3: 00000002e0412004 CR4: 00000000001606e0
  Call Trace:
   rdma_umap_close+0x40/0x90 [ib_uverbs]
   remove_vma+0x43/0x80
   exit_mmap+0xfd/0x1b0
   mmput+0x6e/0x130
   do_exit+0x290/0xcc0
   ? get_signal+0x152/0xc40
   do_group_exit+0x46/0xc0
   get_signal+0x1bd/0xc40
   ? prepare_to_wait_event+0x97/0x190
   do_signal+0x36/0x630
   ? remove_wait_queue+0x60/0x60
   ? __audit_syscall_exit+0x1d9/0x290
   ? rcu_read_lock_sched_held+0x52/0x90
   ? kfree+0x21c/0x2e0
   exit_to_usermode_loop+0x4f/0xc3
   do_syscall_64+0x1ed/0x270
   entry_SYSCALL_64_after_hwframe+0x49/0xbe
  RIP: 0033:0x7fae715a81fd
  Code: Bad RIP value.
  RSP: 002b:00007fae6e163cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
  RAX: fffffffffffffe00 RBX: 00007fae6e163d30 RCX: 00007fae715a81fd
  RDX: 0000000000000010 RSI: 00007fae6e163cf0 RDI: 0000000000000003
  RBP: 00000000013413a0 R08: 00007fae68000000 R09: 0000000000000017
  R10: 0000000000000001 R11: 0000000000000293 R12: 00007fae680008c0
  R13: 00007fae6e163cf0 R14: 00007fae717c9804 R15: 00007fae6e163ed0
  CR2: 0000000100000001
  ---[ end trace b33d58d3a06782cb ]---
  RIP: 0010:rdma_user_mmap_entry_put+0xa/0x30 [ib_core]

Fixes: b86deba977a9 ("RDMA/core: Move core content from ib_uverbs to ib_core")
Link: https://lore.kernel.org/r/20200107162223.1745-1-shiraz.saleem@intel.com
Signed-off-by: Shiraz Saleem 
Signed-off-by: Jason Gunthorpe

IB/hfi1: Adjust flow PSN with the correct resync_psn

2020-01-03T20:48:01+00:00

When a TID RDMA ACK to RESYNC request is received, the flow PSNs for
pending TID RDMA WRITE segments will be adjusted with the next flow
generation number, based on the resync_psn value extracted from the flow
PSN of the TID RDMA ACK packet. The resync_psn value indicates the last
flow PSN for which a TID RDMA WRITE DATA packet has been received by the
responder and the requester should resend TID RDMA WRITE DATA packets,
starting from the next flow PSN.

However, if resync_psn points to the last flow PSN for a segment and the
next segment flow PSN starts with a new generation number, use of the old
resync_psn to adjust the flow PSN for the next segment will lead to
miscalculation, resulting in WARN_ON and sge rewinding errors:

  WARNING: CPU: 4 PID: 146961 at /nfs/site/home/phcvs2/gitrepo/ifs-all/components/Drivers/tmp/rpmbuild/BUILD/ifs-kernel-updates-3.10.0_957.el7.x86_64/hfi1/tid_rdma.c:4764 hfi1_rc_rcv_tid_rdma_ack+0x8f6/0xa90 [hfi1]
  Modules linked in: ib_ipoib(OE) hfi1(OE) rdmavt(OE) rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfsv3 nfs_acl nfs lockd grace fscache iTCO_wdt iTCO_vendor_support skx_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm irqbypass crc32_pclmul ghash_clmulni_intel ib_isert iscsi_target_mod target_core_mod aesni_intel lrw gf128mul glue_helper ablk_helper cryptd rpcrdma sunrpc opa_vnic ast ttm ib_iser libiscsi drm_kms_helper scsi_transport_iscsi ipmi_ssif syscopyarea sysfillrect sysimgblt fb_sys_fops drm joydev ipmi_si pcspkr sg drm_panel_orientation_quirks ipmi_devintf lpc_ich i2c_i801 ipmi_msghandler wmi rdma_ucm ib_ucm ib_uverbs acpi_cpufreq acpi_power_meter ib_umad rdma_cm ib_cm iw_cm ip_tables ext4 mbcache jbd2 sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul i2c_algo_bit crct10dif_common
   crc32c_intel e1000e ib_core ahci libahci ptp libata pps_core nfit libnvdimm [last unloaded: rdmavt]
  CPU: 4 PID: 146961 Comm: kworker/4:0H Kdump: loaded Tainted: G        W  OE  ------------   3.10.0-957.el7.x86_64 #1
  Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.0X.02.0117.040420182310 04/04/2018
  Workqueue: hfi0_0 _hfi1_do_tid_send [hfi1]
  Call Trace:
     [] dump_stack+0x19/0x1b
   [] __warn+0xd8/0x100
   [] warn_slowpath_null+0x1d/0x20
   [] hfi1_rc_rcv_tid_rdma_ack+0x8f6/0xa90 [hfi1]
   [] hfi1_kdeth_eager_rcv+0x1dc/0x210 [hfi1]
   [] ? hfi1_kdeth_expected_rcv+0x1ef/0x210 [hfi1]
   [] kdeth_process_eager+0x35/0x90 [hfi1]
   [] handle_receive_interrupt_nodma_rtail+0x17a/0x2b0 [hfi1]
   [] receive_context_interrupt+0x23/0x40 [hfi1]
   [] __handle_irq_event_percpu+0x44/0x1c0
   [] handle_irq_event_percpu+0x32/0x80
   [] handle_irq_event+0x3c/0x60
   [] handle_edge_irq+0x7f/0x150
   [] handle_irq+0xe4/0x1a0
   [] do_IRQ+0x4d/0xf0
   [] common_interrupt+0x162/0x162
     [] ? swiotlb_map_page+0x49/0x150
   [] hfi1_verbs_send_dma+0x291/0xb70 [hfi1]
   [] ? hfi1_wait_kmem+0xf0/0xf0 [hfi1]
   [] hfi1_verbs_send+0x126/0x2b0 [hfi1]
   [] _hfi1_do_tid_send+0x1d3/0x320 [hfi1]
   [] process_one_work+0x17f/0x440
   [] worker_thread+0x126/0x3c0
   [] ? manage_workers.isra.25+0x2a0/0x2a0
   [] kthread+0xd1/0xe0
   [] ? insert_kthread_work+0x40/0x40
   [] ret_from_fork_nospec_begin+0x7/0x21
   [] ? insert_kthread_work+0x40/0x40

This patch fixes the issue by adjusting the resync_psn first if the flow
generation has been advanced for a pending segment.

Fixes: 9e93e967f7b4 ("IB/hfi1: Add a function to receive TID RDMA ACK packet")
Link: https://lore.kernel.org/r/20191219231920.51069.37147.stgit@awfm-01.aw.intel.com
Cc: 
Reviewed-by: Mike Marciniszyn 
Signed-off-by: Kaike Wan 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe

IB/hfi1: Don't cancel unused work item

2020-01-03T20:41:51+00:00

In the iowait structure, two iowait_work entries were included to queue a
given object: one for normal IB operations, and the other for TID RDMA
operations. For non-TID RDMA operations, the iowait_work structure for TID
RDMA is initialized to contain a NULL function (not used). When the QP is
reset, the function iowait_cancel_work will be called to cancel any
pending work. The problem is that this function will call
cancel_work_sync() for both iowait_work entries, even though the one for
TID RDMA is not used at all. Eventually, the call cascades to
__flush_work(), wherein a WARN_ON will be triggered due to the fact that
work->func is NULL.

The WARN_ON was introduced in commit 4d43d395fed1 ("workqueue: Try to
catch flush_work() without INIT_WORK().")

This patch fixes the issue by making sure that a work function is present
for TID RDMA before calling cancel_work_sync in iowait_cancel_work.

Fixes: 4d43d395fed1 ("workqueue: Try to catch flush_work() without INIT_WORK().")
Fixes: 5da0fc9dbf89 ("IB/hfi1: Prepare resource waits for dual leg")
Link: https://lore.kernel.org/r/20191219211941.58387.39883.stgit@awfm-01.aw.intel.com
Reviewed-by: Mike Marciniszyn 
Signed-off-by: Kaike Wan 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe

RDMA/bnxt_re: Fix Send Work Entry state check while polling completions

2020-01-03T19:27:22+00:00

Some adapters need a fence Work Entry to handle retransmission.  Currently
the driver checks for this condition, only if the Send queue entry is
signalled. Implement the condition check, irrespective of the signalled
state of the Work queue entries

Failure to add the fence can result in access to memory that is already
marked as completed, triggering data corruption, transmission failure,
IOMMU failures, etc.

Fixes: 9152e0b722b2 ("RDMA/bnxt_re: HW workarounds for handling specific conditions")
Link: https://lore.kernel.org/r/1574671174-5064-3-git-send-email-selvin.xavier@broadcom.com
Signed-off-by: Selvin Xavier 
Signed-off-by: Jason Gunthorpe

RDMA/bnxt_re: Avoid freeing MR resources if dereg fails

2020-01-03T19:20:42+00:00

The driver returns an error code for MR dereg, but frees the MR structure.
When the MR dereg is retried due to previous error, the system crashes as
the structure is already freed.

  BUG: unable to handle kernel NULL pointer dereference at 00000000000001b8
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 7 PID: 12178 Comm: ib_send_bw Kdump: loaded Not tainted 4.18.0-124.el8.x86_64 #1
  Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.1.10 03/10/2015
  RIP: 0010:__dev_printk+0x2a/0x70
  Code: 0f 1f 44 00 00 49 89 d1 48 85 f6 0f 84 f6 2b 00 00 4c 8b 46 70 4d 85 c0 75 04 4c 8b
46 10 48 8b 86 a8 00 00 00 48 85 c0 74 16 <48> 8b 08 0f be 7f 01 48 c7 c2 13 ac ac 83 83 ef 30 e9 10 fe ff ff
  RSP: 0018:ffffaf7c04607a60 EFLAGS: 00010006
  RAX: 00000000000001b8 RBX: ffffa0010c91c488 RCX: 0000000000000246
  RDX: ffffaf7c04607a68 RSI: ffffa0010c91caa8 RDI: ffffffff83a788eb
  RBP: ffffaf7c04607ac8 R08: 0000000000000000 R09: ffffaf7c04607a68
  R10: 0000000000000000 R11: 0000000000000001 R12: ffffaf7c04607b90
  R13: 000000000000000e R14: 0000000000000000 R15: 00000000ffffa001
  FS:  0000146fa1f1cdc0(0000) GS:ffffa0012fac0000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00000000000001b8 CR3: 000000007680a003 CR4: 00000000001606e0
  Call Trace:
   dev_err+0x6c/0x90
   ? dev_printk_emit+0x4e/0x70
   bnxt_qplib_rcfw_send_message+0x594/0x660 [bnxt_re]
   ? dev_err+0x6c/0x90
   bnxt_qplib_free_mrw+0x80/0xe0 [bnxt_re]
   bnxt_re_dereg_mr+0x2e/0xd0 [bnxt_re]
   ib_dereg_mr+0x2f/0x50 [ib_core]
   destroy_hw_idr_uobject+0x20/0x70 [ib_uverbs]
   uverbs_destroy_uobject+0x2e/0x170 [ib_uverbs]
   __uverbs_cleanup_ufile+0x6e/0x90 [ib_uverbs]
   uverbs_destroy_ufile_hw+0x61/0x130 [ib_uverbs]
   ib_uverbs_close+0x1f/0x80 [ib_uverbs]
   __fput+0xb7/0x230
   task_work_run+0x8a/0xb0
   do_exit+0x2da/0xb40
...
  RIP: 0033:0x146fa113a387
  Code: Bad RIP value.
  RSP: 002b:00007fff945d1478 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff02
  RAX: 0000000000000000 RBX: 000055a248908d70 RCX: 0000000000000000
  RDX: 0000146fa1f2b000 RSI: 0000000000000001 RDI: 000055a248906488
  RBP: 000055a248909630 R08: 0000000000010000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000000 R12: 000055a248906488
  R13: 0000000000000001 R14: 0000000000000000 R15: 000055a2489095f0

Do not free the MR structures, when driver returns error to the stack.

Fixes: 872f3578241d ("RDMA/bnxt_re: Add support for MRs with Huge pages")
Link: https://lore.kernel.org/r/1574671174-5064-2-git-send-email-selvin.xavier@broadcom.com
Signed-off-by: Selvin Xavier 
Signed-off-by: Jason Gunthorpe

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma

2019-12-15T22:58:13+00:00

Pull rdma fixes from Doug Ledford:
 "A small collection of -rc fixes. Mostly. One API addition, but that's
  because we wanted to use it in a fix. There's also a bug fix that is
  going to render the 5.5 kernel's soft-RoCE driver incompatible with
  all soft-RoCE versions prior, but it's required to actually implement
  the protocol according to the RoCE spec and required in order for the
  soft-RoCE driver to be able to successfully work with actual RoCE
  hardware.

  Summary:

   - Update Steve Wise info

   - Fix for soft-RoCE crc calculations (will break back compatibility,
     but only with the soft-RoCE driver, which has had this bug since it
     was introduced and it is an on-the-wire bug, but will make
     soft-RoCE fully compatible with real RoCE hardware)

   - cma init fixup

   - counters oops fix

   - fix for mlx4 init/teardown sequence

   - fix for mkx5 steering rules

   - introduce a cleanup API, which isn't a fix, but we want to use it
     in the next fix

   - fix for mlx5 memory management that uses API in previous patch"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
  IB/mlx5: Fix device memory flows
  IB/core: Introduce rdma_user_mmap_entry_insert_range() API
  IB/mlx5: Fix steering rule of drop and count
  IB/mlx4: Follow mirror sequence of device add during device removal
  RDMA/counter: Prevent auto-binding a QP which are not tracked with res
  rxe: correctly calculate iCRC for unaligned payloads
  Update mailmap info for Steve Wise
  RDMA/cma: add missed unregister_pernet_subsys in init failure

IB/mlx5: Fix device memory flows

2019-12-12T21:55:36+00:00

Fix device memory flows so that only once there will be no live mmaped
VA to a given allocation the matching object will be destroyed.

This prevents a potential scenario that existing VA that was mmaped by
one process might still be used post its deallocation despite that it's
owned now by other process.

The above is achieved by integrating with IB core APIs to manage
mmap/munmap. Only once the refcount will become 0 the DM object and its
underlay area will be freed.

Fixes: 3b113a1ec3d4 ("IB/mlx5: Support device memory type attribute")
Signed-off-by: Yishai Hadas 
Signed-off-by: Leon Romanovsky 
Link: https://lore.kernel.org/r/20191212100237.330654-3-leon@kernel.org
Signed-off-by: Doug Ledford

IB/core: Introduce rdma_user_mmap_entry_insert_range() API

2019-12-12T21:55:36+00:00

Introduce rdma_user_mmap_entry_insert_range() API to be used once the
required key for the given entry should be in a given range.

Signed-off-by: Yishai Hadas 
Signed-off-by: Leon Romanovsky 
Link: https://lore.kernel.org/r/20191212100237.330654-2-leon@kernel.org
Signed-off-by: Doug Ledford