Hi Don, > -----Original Message----- > From: Don Hiatt [mailto:don.hiatt@xxxxxxxxx] > Sent: Monday, December 04, 2017 11:29 AM > To: Greg KH <greg@xxxxxxxxx>; Parav Pandit <parav@xxxxxxxxxxxx> > Cc: Mike Marciniszyn <mike.marciniszyn@xxxxxxxxx>; stable@xxxxxxxxxxxxxxx; > linux-rdma@xxxxxxxxxxxxxxx; stable-commits@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/2] IB/core: Do not warn on lid conversions for OPA > > > > On 12/4/2017 4:11 AM, Greg KH wrote: > > On Wed, Nov 29, 2017 at 06:17:28PM +0000, Parav Pandit wrote: > >> Hi Mike, > >> > >>> -----Original Message----- > >>> From: linux-rdma-owner@xxxxxxxxxxxxxxx [mailto:linux-rdma- > >>> owner@xxxxxxxxxxxxxxx] On Behalf Of Mike Marciniszyn > >>> Sent: Wednesday, November 29, 2017 7:00 AM > >>> To: stable@xxxxxxxxxxxxxxx > >>> Cc: linux-rdma@xxxxxxxxxxxxxxx; stable-commits@xxxxxxxxxxxxxxx > >>> Subject: [PATCH 1/2] IB/core: Do not warn on lid conversions for OPA > >>> > >>> From: Don Hiatt <don.hiatt@xxxxxxxxx> > >>> > >>> Upstream commit 6588e412fe872ed81f3fb8d9b4561a66ecb763d0. > >>> > >>> On OPA devices the user_mad recv_handler can receive 32Bit LIDs (e.g. > >>> OPA_PERMISSIVE_LID) and it is okay to lose the upper 16 bits of the > >>> LID as this information is obtained elsewhere. Do not issue a > >>> warning when calling > >>> ib_lid_be16() in this case by masking out the upper 16Bits. > >>> > >>> [75667.310846] ------------[ cut here ]------------ [75667.316447] WARNING: > >>> CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3799 > >>> recv_handler+0x15a/0x170 [ib_umad] [75667.327640] Modules linked in: > >>> ib_ipoib hfi1(E) rdmavt(E) > >>> rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) > >>> ib_uverbs(E) > >>> ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash > >>> dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp > kvm > >>> irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc > >>> aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd > >>> ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp > >>> ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter > >>> acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs > >>> libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect > >>> sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel > libata dca i2c_algo_bit i2c_core [last unloaded: ib_core] > >>> [75667.407704] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E > >>> 4.13.0-rc7+ #1 > >>> [75667.417310] Hardware name: Intel Corporation S2600WT2/S2600WT2, > >>> BIOS > >>> SE5C610.86B.01.01.0008.021120151325 02/11/2015 [75667.429555] > >>> Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] [75667.436360] task: > >>> ffff88084a718000 task.stack: ffffc9000a424000 [75667.443549] RIP: > >>> 0010:recv_handler+0x15a/0x170 [ib_umad] [75667.450090] RSP: > >>> 0018:ffffc9000a427ce8 EFLAGS: 00010286 [75667.456508] RAX: > >>> 00000000ffffffff RBX: ffff88085159ce80 RCX: 0000000000000000 > >>> [75667.465094] RDX: ffff88085a47b068 RSI: 0000000000000000 RDI: > >>> ffff88085159cf00 [75667.473668] RBP: ffffc9000a427d38 R08: > >>> 000000000001efc0 R09: ffff88085159ce80 [75667.482228] R10: > >>> ffff88085f007480 R11: ffff88084acf20e8 R12: ffff88085a47b020 > >>> [75667.490824] R13: ffff881056842e10 R14: ffff881056840200 R15: > >>> ffff88104c8d0800 [75667.499390] FS: 0000000000000000(0000) > >>> GS:ffff88085f400000(0000) knlGS:0000000000000000 [75667.509028] CS: > >>> 0010 > >>> DS: 0000 ES: 0000 CR0: 0000000080050033 [75667.516080] CR2: > >>> 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0 > >>> [75667.524664] Call Trace: > >>> [75667.528044] ? find_mad_agent+0x7c/0x1b0 [ib_core] [75667.534031] ? > >>> ib_mark_mad_done+0x73/0xa0 [ib_core] [75667.540142] > >>> ib_mad_recv_done+0x423/0x9b0 [ib_core] [75667.546215] > >>> __ib_process_cq+0x5d/0xb0 [ib_core] [75667.552007] > >>> ib_cq_poll_work+0x20/0x60 [ib_core] [75667.557766] > >>> process_one_work+0x149/0x360 [75667.562844] > >>> worker_thread+0x4d/0x3c0 [75667.567529] kthread+0x109/0x140 > [75667.571713] ? > >>> rescuer_thread+0x380/0x380 [75667.576775] ? kthread_park+0x60/0x60 > >>> [75667.581447] ret_from_fork+0x25/0x30 [75667.586014] Code: 43 4a > >>> 0f b6 > >>> 45 c6 88 43 4b 48 8b 45 b0 48 89 43 4c 48 8b 45 b8 48 89 43 54 8b 45 > >>> c0 0f c8 89 > >>> 43 5c e9 79 ff ff ff e8 16 4e fa e0 <0f> ff e9 42 ff ff ff 66 66 66 > >>> 66 66 66 2e 0f 1f > >>> 84 00 00 00 00 [75667.608323] ---[ end trace cf26df27c9597264 ]--- > >>> > >>> Cc: <stable@xxxxxxxxxxxxxxx> # 4.14.x > >>> Fixes: 62ede7779904 ("Add OPA extended LID support") > >>> Reviewed-by: Mike Marciniszyn <mike.marciniszyn@xxxxxxxxx> > >>> Signed-off-by: Don Hiatt <don.hiatt@xxxxxxxxx> > >>> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@xxxxxxxxx> > >>> Reviewed-by: Leon Romanovsky <leonro@xxxxxxxxxxxx> > >>> Signed-off-by: Doug Ledford <dledford@xxxxxxxxxx> > >>> --- > >>> drivers/infiniband/core/user_mad.c | 11 ++++++++++- > >>> 1 file changed, 10 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/infiniband/core/user_mad.c > >>> b/drivers/infiniband/core/user_mad.c > >>> index c1696e6..603acaf 100644 > >>> --- a/drivers/infiniband/core/user_mad.c > >>> +++ b/drivers/infiniband/core/user_mad.c > >>> @@ -229,7 +229,16 @@ static void recv_handler(struct ib_mad_agent > *agent, > >>> packet->mad.hdr.status = 0; > >>> packet->mad.hdr.length = hdr_size(file) + mad_recv_wc->mad_len; > >>> packet->mad.hdr.qpn = cpu_to_be32(mad_recv_wc->wc->src_qp); > >>> - packet->mad.hdr.lid = ib_lid_be16(mad_recv_wc->wc->slid); > >>> + /* > >>> + * On OPA devices it is okay to lose the upper 16 bits of LID as this > >>> + * information is obtained elsewhere. Mask off the upper 16 bits. > >>> + */ > >>> + if (agent->device->port_immutable[agent->port_num].core_cap_flags > >>> & > >>> + RDMA_CORE_PORT_INTEL_OPA) > >> Can you please use existing API rdma_cap_opa_mad() here? > > This patch is already upstream, please fix it there if you really want > > to make this change. > Hi Parav, > > I have changes for this that I can submit as a follow on patch, please let me > know if this is how you'd like to proceed. > Follow changes are fine to me.