<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/infiniband/core/netlink.c, branch v6.2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-06-21T18:38:30+00:00</updated>
<entry>
<title>RDMA/core: Fix incorrect print format specifier</title>
<updated>2021-06-21T18:38:30+00:00</updated>
<author>
<name>Wenpeng Liang</name>
<email>liangwenpeng@huawei.com</email>
</author>
<published>2021-06-10T11:40:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3cea7b4a7d9b3cb8036ca799fe4254a710cd7e40'/>
<id>urn:sha1:3cea7b4a7d9b3cb8036ca799fe4254a710cd7e40</id>
<content type='text'>
There are some '%u' for 'int' and '%d' for 'unsigend int', they should be
fixed.

Link: https://lore.kernel.org/r/1623325232-30900-1-git-send-email-liweihang@huawei.com
Signed-off-by: Wenpeng Liang &lt;liangwenpeng@huawei.com&gt;
Signed-off-by: Weihang Li &lt;liweihang@huawei.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>IB/core: Avoid deadlock during netlink message handling</title>
<updated>2019-10-24T23:49:37+00:00</updated>
<author>
<name>Parav Pandit</name>
<email>parav@mellanox.com</email>
</author>
<published>2019-10-15T08:07:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=549af00833028b5803528553a4743e0cd1fdbee9'/>
<id>urn:sha1:549af00833028b5803528553a4743e0cd1fdbee9</id>
<content type='text'>
When rdmacm module is not loaded, and when netlink message is received to
get char device info, it results into a deadlock due to recursive locking
of rdma_nl_mutex with the below call sequence.

[..]
  rdma_nl_rcv()
  mutex_lock()
   [..]
   rdma_nl_rcv_msg()
      ib_get_client_nl_info()
         request_module()
           iw_cm_init()
             rdma_nl_register()
               mutex_lock(); &lt;- Deadlock, acquiring mutex again

Due to above call sequence, following call trace and deadlock is observed.

  kernel: __mutex_lock+0x35e/0x860
  kernel: ? __mutex_lock+0x129/0x860
  kernel: ? rdma_nl_register+0x1a/0x90 [ib_core]
  kernel: rdma_nl_register+0x1a/0x90 [ib_core]
  kernel: ? 0xffffffffc029b000
  kernel: iw_cm_init+0x34/0x1000 [iw_cm]
  kernel: do_one_initcall+0x67/0x2d4
  kernel: ? kmem_cache_alloc_trace+0x1ec/0x2a0
  kernel: do_init_module+0x5a/0x223
  kernel: load_module+0x1998/0x1e10
  kernel: ? __symbol_put+0x60/0x60
  kernel: __do_sys_finit_module+0x94/0xe0
  kernel: do_syscall_64+0x5a/0x270
  kernel: entry_SYSCALL_64_after_hwframe+0x49/0xbe

  process stack trace:
  [&lt;0&gt;] __request_module+0x1c9/0x460
  [&lt;0&gt;] ib_get_client_nl_info+0x5e/0xb0 [ib_core]
  [&lt;0&gt;] nldev_get_chardev+0x1ac/0x320 [ib_core]
  [&lt;0&gt;] rdma_nl_rcv_msg+0xeb/0x1d0 [ib_core]
  [&lt;0&gt;] rdma_nl_rcv+0xcd/0x120 [ib_core]
  [&lt;0&gt;] netlink_unicast+0x179/0x220
  [&lt;0&gt;] netlink_sendmsg+0x2f6/0x3f0
  [&lt;0&gt;] sock_sendmsg+0x30/0x40
  [&lt;0&gt;] ___sys_sendmsg+0x27a/0x290
  [&lt;0&gt;] __sys_sendmsg+0x58/0xa0
  [&lt;0&gt;] do_syscall_64+0x5a/0x270
  [&lt;0&gt;] entry_SYSCALL_64_after_hwframe+0x49/0xbe

To overcome this deadlock and to allow multiple netlink messages to
progress in parallel, following scheme is implemented.

1. Split the lock protecting the cb_table into a per-index lock, and make
   it a rwlock. This lock is used to ensure no callbacks are running after
   unregistration returns. Since a module will not be registered once it
   is already running callbacks, this avoids the deadlock.

2. Use smp_store_release() to update the cb_table during registration so
   that no lock is required. This avoids lockdep problems with thinking
   all the rwsems are the same lock class.

Fixes: 0e2d00eb6fd45 ("RDMA: Add NLDEV_GET_CHARDEV to allow char dev discovery and autoload")
Link: https://lore.kernel.org/r/20191015080733.18625-1-leon@kernel.org
Signed-off-by: Parav Pandit &lt;parav@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>RDMA/core: fix spelling mistake "Nelink" -&gt; "Netlink"</title>
<updated>2019-07-31T15:54:33+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2019-07-31T08:01:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1dc558923c5ceab0b4eb78dc0050ea4c4aa1accc'/>
<id>urn:sha1:1dc558923c5ceab0b4eb78dc0050ea4c4aa1accc</id>
<content type='text'>
There is a spelling mistake in a warning message, fix it.

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Reviewed-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Link: https://lore.kernel.org/r/20190731080144.18327-1-colin.king@canonical.com
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
</entry>
<entry>
<title>RDMA/core: Support netlink commands in non init_net net namespaces</title>
<updated>2019-07-25T17:12:41+00:00</updated>
<author>
<name>Parav Pandit</name>
<email>parav@mellanox.com</email>
</author>
<published>2019-07-23T07:02:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1d2fedd8561dc469a7503855ee602f4bb3eccfa7'/>
<id>urn:sha1:1d2fedd8561dc469a7503855ee602f4bb3eccfa7</id>
<content type='text'>
Now that IB core supports RDMA device binding with specific net namespace,
enable IB core to accept netlink commands in non init_net namespaces.

This is done by having per net namespace netlink socket.

At present only netlink device handling client RDMA_NL_NLDEV supports
device handling in multiple net namespaces.  Hence do not accept netlink
messages for other clients in non init_net net namespaces.

Link: https://lore.kernel.org/r/20190723070205.6247-1-leon@kernel.org
Signed-off-by: Parav Pandit &lt;parav@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>RDMA/cma: Remove CM_ID statistics provided by rdma-cm module</title>
<updated>2019-02-05T22:30:33+00:00</updated>
<author>
<name>Leon Romanovsky</name>
<email>leonro@mellanox.com</email>
</author>
<published>2019-01-16T07:55:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a78e8723a50530d15faa25cc0b6f009bcd251c20'/>
<id>urn:sha1:a78e8723a50530d15faa25cc0b6f009bcd251c20</id>
<content type='text'>
Netlink statistics exported by rdma-cm never had any working user space
component published to the mailing list or to any open source
project. Canvassing various proprietary users, and the original requester,
we find that there are no real users of this interface.

This patch simply removes all occurrences of RDMA CM netlink in favour of
modern nldev implementation, which provides the same information and
accompanied by widely used user space component.

Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Reviewed-by: Steve Wise &lt;swise@opengridcomputing.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>RDMA/netlink: Simplify netlink listener existence check</title>
<updated>2018-10-03T22:06:07+00:00</updated>
<author>
<name>Leon Romanovsky</name>
<email>leonro@mellanox.com</email>
</author>
<published>2018-10-02T08:49:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=38716732f161c3d107c4cc406a287f1201bed752'/>
<id>urn:sha1:38716732f161c3d107c4cc406a287f1201bed752</id>
<content type='text'>
All users of rdma_nl_chk_listeners() are interested to get boolean answer
if netlink socket has listeners, so update all places to boolean function.

Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Reviewed-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>RDMA/netlink: Simplify code of autoload modules</title>
<updated>2018-01-02T20:36:57+00:00</updated>
<author>
<name>Leon Romanovsky</name>
<email>leonro@mellanox.com</email>
</author>
<published>2018-01-01T11:07:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b823369b6faa33cc71b65eef9bebcefe622913dc'/>
<id>urn:sha1:b823369b6faa33cc71b65eef9bebcefe622913dc</id>
<content type='text'>
The request_module() call is internally wrapped by CONFIG_MODULE,
so there is no need to check it in our RDMA code too.

Refactor to simplify the code.

Reviewed-by: Mark Bloch &lt;markb@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>drivers: infiniband: remove duplicate includes</title>
<updated>2017-12-22T16:39:35+00:00</updated>
<author>
<name>Pravin Shedge</name>
<email>pravin.shedge4linux@gmail.com</email>
</author>
<published>2017-12-06T16:49:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=72c7fe90ee7a16a8e350183712b2a639b4054ace'/>
<id>urn:sha1:72c7fe90ee7a16a8e350183712b2a639b4054ace</id>
<content type='text'>
These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.

Signed-off-by: Pravin Shedge &lt;pravin.shedge4linux@gmail.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>RDMA/netlink: OOPs in rdma_nl_rcv_msg() from misinterpreted flag</title>
<updated>2017-10-25T18:54:43+00:00</updated>
<author>
<name>Michael J. Ruhl</name>
<email>michael.j.ruhl@intel.com</email>
</author>
<published>2017-10-24T12:41:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b4d91aeb6e120b7e2f207021c31b914895c69bc4'/>
<id>urn:sha1:b4d91aeb6e120b7e2f207021c31b914895c69bc4</id>
<content type='text'>
rdma_nl_rcv_msg() checks to see if it should use the .dump() callback
or the .doit() callback.  The check is done with this check:

if (flags &amp; NLM_F_DUMP) ...

The NLM_F_DUMP flag is two bits (NLM_F_ROOT | NLM_F_MATCH).

When an RDMA_NL_LS message (response) is received, the bit used for
indicating an error is the same bit as NLM_F_ROOT.

NLM_F_ROOT == (0x100) == RDMA_NL_LS_F_ERR.

ibacm sends a response with the RDMA_NL_LS_F_ERR bit set if an error
occurs in the service.  The current code then misinterprets the
NLM_F_DUMP bit and trys to call the .dump() callback.

If the .dump() callback for the specified request is not available
(which is true for the RDMA_NL_LS messages) the following Oops occurs:

[ 4555.960256] BUG: unable to handle kernel NULL pointer dereference at
   (null)
[ 4555.969046] IP:           (null)
[ 4555.972664] PGD 10543f1067 P4D 10543f1067 PUD 1033f93067 PMD 0
[ 4555.979287] Oops: 0010 [#1] SMP
[ 4555.982809] Modules linked in: rpcrdma ib_isert iscsi_target_mod
target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_ucm ib_ucm
ib_uverbs ib_umad rdma_cm ib_cm iw_cm dm_mirror dm_region_hash dm_log dm_mod
dax sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd
glue_helper cryptd hfi1 rdmavt iTCO_wdt iTCO_vendor_support ib_core mei_me
lpc_ich pcspkr mei ioatdma sg shpchp i2c_i801 mfd_core wmi ipmi_si ipmi_devintf
ipmi_msghandler acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace
sunrpc ip_tables ext4 mbcache jbd2 sd_mod mgag200 drm_kms_helper syscopyarea
sysfillrect sysimgblt fb_sys_fops ttm igb ahci crc32c_intel ptp libahci
pps_core drm dca libata i2c_algo_bit i2c_core
[ 4556.061190] CPU: 54 PID: 9841 Comm: ibacm Tainted: G          I
4.14.0-rc2+ #6
[ 4556.069667] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS
SE5C610.86B.01.01.0008.021120151325 02/11/2015
[ 4556.081339] task: ffff880855f42d00 task.stack: ffffc900246b4000
[ 4556.087967] RIP: 0010:          (null)
[ 4556.092166] RSP: 0018:ffffc900246b7bc8 EFLAGS: 00010246
[ 4556.098018] RAX: ffffffff81dbe9e0 RBX: ffff881058bb1000 RCX:
0000000000000000
[ 4556.105997] RDX: 0000000000001100 RSI: ffff881058bb1320 RDI:
ffff881056362000
[ 4556.113984] RBP: ffffc900246b7bf8 R08: 0000000000000ec0 R09:
0000000000001100
[ 4556.121971] R10: ffff8810573a5000 R11: 0000000000000000 R12:
ffff881056362000
[ 4556.129957] R13: 0000000000000ec0 R14: ffff881058bb1320 R15:
0000000000000ec0
[ 4556.137945] FS:  00007fe0ba5a38c0(0000) GS:ffff88105f080000(0000)
knlGS:0000000000000000
[ 4556.147000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4556.153433] CR2: 0000000000000000 CR3: 0000001056f5d003 CR4:
00000000001606e0
[ 4556.161419] Call Trace:
[ 4556.164167]  ? netlink_dump+0x12c/0x290
[ 4556.168468]  __netlink_dump_start+0x186/0x1f0
[ 4556.173357]  rdma_nl_rcv_msg+0x193/0x1b0 [ib_core]
[ 4556.178724]  rdma_nl_rcv+0xdc/0x130 [ib_core]
[ 4556.183604]  netlink_unicast+0x181/0x240
[ 4556.187998]  netlink_sendmsg+0x2c2/0x3b0
[ 4556.192392]  sock_sendmsg+0x38/0x50
[ 4556.196299]  SYSC_sendto+0x102/0x190
[ 4556.200308]  ? __audit_syscall_entry+0xaf/0x100
[ 4556.205387]  ? syscall_trace_enter+0x1d0/0x2b0
[ 4556.210366]  ? __audit_syscall_exit+0x209/0x290
[ 4556.215442]  SyS_sendto+0xe/0x10
[ 4556.219060]  do_syscall_64+0x67/0x1b0
[ 4556.223165]  entry_SYSCALL64_slow_path+0x25/0x25
[ 4556.228328] RIP: 0033:0x7fe0b9db2a63
[ 4556.232333] RSP: 002b:00007ffc55edc260 EFLAGS: 00000293 ORIG_RAX:
000000000000002c
[ 4556.240808] RAX: ffffffffffffffda RBX: 0000000000000010 RCX:
00007fe0b9db2a63
[ 4556.248796] RDX: 0000000000000010 RSI: 00007ffc55edc280 RDI:
000000000000000d
[ 4556.256782] RBP: 00007ffc55edc670 R08: 00007ffc55edc270 R09:
000000000000000c
[ 4556.265321] R10: 0000000000000000 R11: 0000000000000293 R12:
00007ffc55edc280
[ 4556.273846] R13: 000000000260b400 R14: 000000000000000d R15:
0000000000000001
[ 4556.282368] Code:  Bad RIP value.
[ 4556.286629] RIP:           (null) RSP: ffffc900246b7bc8
[ 4556.293013] CR2: 0000000000000000
[ 4556.297292] ---[ end trace 8d67abcfd10ec209 ]---
[ 4556.305465] Kernel panic - not syncing: Fatal exception
[ 4556.313786] Kernel Offset: disabled
[ 4556.321563] ---[ end Kernel panic - not syncing: Fatal exception
[ 4556.328960] ------------[ cut here ]------------

Special case RDMA_NL_LS response messages to call the appropriate
callback.

Additionally, make sure that the .dump() callback is not NULL
before calling it.

Fixes: 647c75ac59a48a54 ("RDMA/netlink: Convert LS to doit callback")
Reviewed-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Reviewed-by: Kaike Wan &lt;kaike.wan@intel.com&gt;
Reviewed-by: Alex Estrin &lt;alex.estrin@intel.com&gt;
Signed-off-by: Michael J. Ruhl &lt;michael.j.ruhl@intel.com&gt;
Reviewed-by: Shiraz Saleem &lt;shiraz.saleem@intel.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
</entry>
<entry>
<title>RDMA/netlink: clean up message validity array initializer</title>
<updated>2017-09-08T17:17:20+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-09-08T17:17:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=015a9e66b9b8c1f28097ed09bf9350708e26249a'/>
<id>urn:sha1:015a9e66b9b8c1f28097ed09bf9350708e26249a</id>
<content type='text'>
The fix in the parent made me look at that function, and react to how
illogical and illegible the array initializer was.

Use named array indexes to make it clearer what is going on, and make
the initializer not depend silently on the exact index numbers.

[ The initializer now also shows an odd inconsistency in the naming:
  note the IWCM vs IWPM..   - Linus ]

Cc: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Cc: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
