<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/infiniband/ulp, branch v5.10.78</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>IB/isert: Align target max I/O size to initiator size</title>
<updated>2021-07-19T07:44:53+00:00</updated>
<author>
<name>Max Gurtovoy</name>
<email>mgurtovoy@nvidia.com</email>
</author>
<published>2021-05-24T08:52:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d8bb134d808c7ed778df1f9bb71e51bad55d7a81'/>
<id>d8bb134d808c7ed778df1f9bb71e51bad55d7a81</id>
<content type='text'>
[ Upstream commit 109d19a5eb3ddbdb87c43bfd4bcf644f4569da64 ]

Since the Linux iser initiator default max I/O size set to 512KB and since
there is no handshake procedure for this size in iser protocol, set the
default max IO size of the target to 512KB as well.

For changing the default values, there is a module parameter for both
drivers.

Link: https://lore.kernel.org/r/20210524085215.29005-1-mgurtovoy@nvidia.com
Reviewed-by: Alaa Hleihel &lt;alaa@nvidia.com&gt;
Reviewed-by: Israel Rukshin &lt;israelr@nvidia.com&gt;
Signed-off-by: Max Gurtovoy &lt;mgurtovoy@nvidia.com&gt;
Acked-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 109d19a5eb3ddbdb87c43bfd4bcf644f4569da64 ]

Since the Linux iser initiator default max I/O size set to 512KB and since
there is no handshake procedure for this size in iser protocol, set the
default max IO size of the target to 512KB as well.

For changing the default values, there is a module parameter for both
drivers.

Link: https://lore.kernel.org/r/20210524085215.29005-1-mgurtovoy@nvidia.com
Reviewed-by: Alaa Hleihel &lt;alaa@nvidia.com&gt;
Reviewed-by: Israel Rukshin &lt;israelr@nvidia.com&gt;
Signed-off-by: Max Gurtovoy &lt;mgurtovoy@nvidia.com&gt;
Acked-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/rtrs: Change MAX_SESS_QUEUE_DEPTH</title>
<updated>2021-07-19T07:44:43+00:00</updated>
<author>
<name>Gioh Kim</name>
<email>gi-oh.kim@cloud.ionos.com</email>
</author>
<published>2021-05-28T11:30:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=315988817aa770044fbb9e16af5c0dd9344da188'/>
<id>315988817aa770044fbb9e16af5c0dd9344da188</id>
<content type='text'>
[ Upstream commit 3a98ea7041b7d18ac356da64823c2ba2f8391b3e ]

Max IB immediate data size is 2^28 (MAX_IMM_PAYL_BITS)
and the minimum chunk size is 4096 (2^12).
Therefore the maximum sess_queue_depth is 65536 (2^16).

Link: https://lore.kernel.org/r/20210528113018.52290-6-jinpu.wang@ionos.com
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3a98ea7041b7d18ac356da64823c2ba2f8391b3e ]

Max IB immediate data size is 2^28 (MAX_IMM_PAYL_BITS)
and the minimum chunk size is 4096 (2^12).
Therefore the maximum sess_queue_depth is 65536 (2^16).

Link: https://lore.kernel.org/r/20210528113018.52290-6-jinpu.wang@ionos.com
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/rtrs-srv: Set minimal max_send_wr and max_recv_wr</title>
<updated>2021-07-14T14:56:23+00:00</updated>
<author>
<name>Jack Wang</name>
<email>jinpu.wang@cloud.ionos.com</email>
</author>
<published>2021-06-14T09:03:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fcd8d6371a469aae96367f82a14870e4beef8b2f'/>
<id>fcd8d6371a469aae96367f82a14870e4beef8b2f</id>
<content type='text'>
[ Upstream commit 5e91eabf66c854f16ca2e954e5c68939bc81601e ]

Currently rtrs when create_qp use a coarse numbers (bigger in general),
which leads to hardware create more resources which only waste memory with
no benefits.

For max_send_wr, we don't really need alway max_qp_wr size when creating
qp, reduce it to cq_size.

For max_recv_wr,  cq_size is enough.

With the patch when sess_queue_depth=128, per session (2 paths) memory
consumption reduced from 188 MB to 65MB

When always_invalidate is enabled, we need send more wr, so treat it
special.

Fixes: 9cb837480424e ("RDMA/rtrs: server: main functionality")
Link: https://lore.kernel.org/r/20210614090337.29557-2-jinpu.wang@ionos.com
Signed-off-by: Jack Wang &lt;jinpu.wang@cloud.ionos.com&gt;
Reviewed-by: Md Haris Iqbal &lt;haris.iqbal@cloud.ionos.com&gt;
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Reviewed-by: Leon Romanovsky &lt;leonro@nvidia.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5e91eabf66c854f16ca2e954e5c68939bc81601e ]

Currently rtrs when create_qp use a coarse numbers (bigger in general),
which leads to hardware create more resources which only waste memory with
no benefits.

For max_send_wr, we don't really need alway max_qp_wr size when creating
qp, reduce it to cq_size.

For max_recv_wr,  cq_size is enough.

With the patch when sess_queue_depth=128, per session (2 paths) memory
consumption reduced from 188 MB to 65MB

When always_invalidate is enabled, we need send more wr, so treat it
special.

Fixes: 9cb837480424e ("RDMA/rtrs: server: main functionality")
Link: https://lore.kernel.org/r/20210614090337.29557-2-jinpu.wang@ionos.com
Signed-off-by: Jack Wang &lt;jinpu.wang@cloud.ionos.com&gt;
Reviewed-by: Md Haris Iqbal &lt;haris.iqbal@cloud.ionos.com&gt;
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Reviewed-by: Leon Romanovsky &lt;leonro@nvidia.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/rtrs-clt: Fix memory leak of not-freed sess-&gt;stats and stats-&gt;pcpu_stats</title>
<updated>2021-07-14T14:56:18+00:00</updated>
<author>
<name>Gioh Kim</name>
<email>gi-oh.kim@cloud.ionos.com</email>
</author>
<published>2021-05-28T11:30:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6cbc167bc13259ab9bee9b39b85726f15332a4e3'/>
<id>6cbc167bc13259ab9bee9b39b85726f15332a4e3</id>
<content type='text'>
[ Upstream commit 7ecd7e290bee0ab9cf75b79a367a4cc113cf8292 ]

sess-&gt;stats and sess-&gt;stats-&gt;pcpu_stats objects are freed
when sysfs entry is removed. If something wrong happens and
session is closed before sysfs entry is created,
sess-&gt;stats and sess-&gt;stats-&gt;pcpu_stats objects are not freed.

This patch adds freeing of them at three places:
1. When client uses wrong address and session creation fails.
2. When client fails to create a sysfs entry.
3. When client adds wrong address via sysfs add_path.

Fixes: 215378b838df0 ("RDMA/rtrs: client: sysfs interface functions")
Link: https://lore.kernel.org/r/20210528113018.52290-21-jinpu.wang@ionos.com
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7ecd7e290bee0ab9cf75b79a367a4cc113cf8292 ]

sess-&gt;stats and sess-&gt;stats-&gt;pcpu_stats objects are freed
when sysfs entry is removed. If something wrong happens and
session is closed before sysfs entry is created,
sess-&gt;stats and sess-&gt;stats-&gt;pcpu_stats objects are not freed.

This patch adds freeing of them at three places:
1. When client uses wrong address and session creation fails.
2. When client fails to create a sysfs entry.
3. When client adds wrong address via sysfs add_path.

Fixes: 215378b838df0 ("RDMA/rtrs: client: sysfs interface functions")
Link: https://lore.kernel.org/r/20210528113018.52290-21-jinpu.wang@ionos.com
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/rtrs-clt: Check if the queue_depth has changed during a reconnection</title>
<updated>2021-07-14T14:56:18+00:00</updated>
<author>
<name>Md Haris Iqbal</name>
<email>haris.iqbal@cloud.ionos.com</email>
</author>
<published>2021-05-28T11:30:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6569ae1deb6c3702084630868d7d1c69a5231a6f'/>
<id>6569ae1deb6c3702084630868d7d1c69a5231a6f</id>
<content type='text'>
[ Upstream commit 5b73b799c25c68a4703cd6c5ac4518006d9865b8 ]

The queue_depth is a module parameter for rtrs_server. It is used on the
client side to determing the queue_depth of the request queue for the RNBD
virtual block device.

During a reconnection event for an already mapped device, in case the
rtrs_server module queue_depth has changed, fail the reconnect attempt.

Also stop further auto reconnection attempts. A manual reconnect via
sysfs has to be triggerred.

Fixes: 6a98d71daea18 ("RDMA/rtrs: client: main functionality")
Link: https://lore.kernel.org/r/20210528113018.52290-20-jinpu.wang@ionos.com
Signed-off-by: Md Haris Iqbal &lt;haris.iqbal@ionos.com&gt;
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5b73b799c25c68a4703cd6c5ac4518006d9865b8 ]

The queue_depth is a module parameter for rtrs_server. It is used on the
client side to determing the queue_depth of the request queue for the RNBD
virtual block device.

During a reconnection event for an already mapped device, in case the
rtrs_server module queue_depth has changed, fail the reconnect attempt.

Also stop further auto reconnection attempts. A manual reconnect via
sysfs has to be triggerred.

Fixes: 6a98d71daea18 ("RDMA/rtrs: client: main functionality")
Link: https://lore.kernel.org/r/20210528113018.52290-20-jinpu.wang@ionos.com
Signed-off-by: Md Haris Iqbal &lt;haris.iqbal@ionos.com&gt;
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/rtrs-srv: Fix memory leak when having multiple sessions</title>
<updated>2021-07-14T14:56:18+00:00</updated>
<author>
<name>Jack Wang</name>
<email>jinpu.wang@cloud.ionos.com</email>
</author>
<published>2021-05-28T11:30:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8651ad0e29682bb27785948c9b59b9683af7c90c'/>
<id>8651ad0e29682bb27785948c9b59b9683af7c90c</id>
<content type='text'>
[ Upstream commit 6bb97a2c1aa5278a30d49abb6186d50c34c207e2 ]

Gioh notice memory leak below
unreferenced object 0xffff8880acda2000 (size 2048):
  comm "kworker/4:1", pid 77, jiffies 4295062871 (age 1270.730s)
  hex dump (first 32 bytes):
    00 20 da ac 80 88 ff ff 00 20 da ac 80 88 ff ff  . ....... ......
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;00000000e85d85b5&gt;] rtrs_srv_rdma_cm_handler+0x8e5/0xa90 [rtrs_server]
    [&lt;00000000e31a988a&gt;] cma_ib_req_handler+0xdc5/0x2b50 [rdma_cm]
    [&lt;000000000eb02c5b&gt;] cm_process_work+0x2d/0x100 [ib_cm]
    [&lt;00000000e1650ca9&gt;] cm_req_handler+0x11bc/0x1c40 [ib_cm]
    [&lt;000000009c28818b&gt;] cm_work_handler+0xe65/0x3cf2 [ib_cm]
    [&lt;000000002b53eaa1&gt;] process_one_work+0x4bc/0x980
    [&lt;00000000da3499fb&gt;] worker_thread+0x78/0x5c0
    [&lt;00000000167127a4&gt;] kthread+0x191/0x1e0
    [&lt;0000000060802104&gt;] ret_from_fork+0x3a/0x50
unreferenced object 0xffff88806d595d90 (size 8):
  comm "kworker/4:1H", pid 131, jiffies 4295062972 (age 1269.720s)
  hex dump (first 8 bytes):
    62 6c 61 00 6b 6b 6b a5                          bla.kkk.
  backtrace:
    [&lt;000000004447d253&gt;] kstrdup+0x2e/0x60
    [&lt;0000000047259793&gt;] kobject_set_name_vargs+0x2f/0xb0
    [&lt;00000000c2ee3bc8&gt;] dev_set_name+0xab/0xe0
    [&lt;000000002b6bdfb1&gt;] rtrs_srv_create_sess_files+0x260/0x290 [rtrs_server]
    [&lt;0000000075d87bd7&gt;] rtrs_srv_info_req_done+0x71b/0x960 [rtrs_server]
    [&lt;00000000ccdf1bb5&gt;] __ib_process_cq+0x94/0x100 [ib_core]
    [&lt;00000000cbcb60cb&gt;] ib_cq_poll_work+0x32/0xc0 [ib_core]
    [&lt;000000002b53eaa1&gt;] process_one_work+0x4bc/0x980
    [&lt;00000000da3499fb&gt;] worker_thread+0x78/0x5c0
    [&lt;00000000167127a4&gt;] kthread+0x191/0x1e0
    [&lt;0000000060802104&gt;] ret_from_fork+0x3a/0x50
unreferenced object 0xffff88806d6bb100 (size 256):
  comm "kworker/4:1H", pid 131, jiffies 4295062972 (age 1269.720s)
  hex dump (first 32 bytes):
    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
    ff ff ff ff ff ff ff ff 00 59 4d 86 ff ff ff ff  .........YM.....
  backtrace:
    [&lt;00000000a18a11e4&gt;] device_add+0x74d/0xa00
    [&lt;00000000a915b95f&gt;] rtrs_srv_create_sess_files.cold+0x49/0x1fe [rtrs_server]
    [&lt;0000000075d87bd7&gt;] rtrs_srv_info_req_done+0x71b/0x960 [rtrs_server]
    [&lt;00000000ccdf1bb5&gt;] __ib_process_cq+0x94/0x100 [ib_core]
    [&lt;00000000cbcb60cb&gt;] ib_cq_poll_work+0x32/0xc0 [ib_core]
    [&lt;000000002b53eaa1&gt;] process_one_work+0x4bc/0x980
    [&lt;00000000da3499fb&gt;] worker_thread+0x78/0x5c0
    [&lt;00000000167127a4&gt;] kthread+0x191/0x1e0
    [&lt;0000000060802104&gt;] ret_from_fork+0x3a/0x50

The problem is we increase device refcount by get_device in process_info_req
for each path, but only does put_deice for last path, which lead to
memory leak.

To fix it, it also calls put_device when dev_ref is not 0.

Fixes: e2853c49477d1 ("RDMA/rtrs-srv-sysfs: fix missing put_device")
Link: https://lore.kernel.org/r/20210528113018.52290-19-jinpu.wang@ionos.com
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 6bb97a2c1aa5278a30d49abb6186d50c34c207e2 ]

Gioh notice memory leak below
unreferenced object 0xffff8880acda2000 (size 2048):
  comm "kworker/4:1", pid 77, jiffies 4295062871 (age 1270.730s)
  hex dump (first 32 bytes):
    00 20 da ac 80 88 ff ff 00 20 da ac 80 88 ff ff  . ....... ......
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;00000000e85d85b5&gt;] rtrs_srv_rdma_cm_handler+0x8e5/0xa90 [rtrs_server]
    [&lt;00000000e31a988a&gt;] cma_ib_req_handler+0xdc5/0x2b50 [rdma_cm]
    [&lt;000000000eb02c5b&gt;] cm_process_work+0x2d/0x100 [ib_cm]
    [&lt;00000000e1650ca9&gt;] cm_req_handler+0x11bc/0x1c40 [ib_cm]
    [&lt;000000009c28818b&gt;] cm_work_handler+0xe65/0x3cf2 [ib_cm]
    [&lt;000000002b53eaa1&gt;] process_one_work+0x4bc/0x980
    [&lt;00000000da3499fb&gt;] worker_thread+0x78/0x5c0
    [&lt;00000000167127a4&gt;] kthread+0x191/0x1e0
    [&lt;0000000060802104&gt;] ret_from_fork+0x3a/0x50
unreferenced object 0xffff88806d595d90 (size 8):
  comm "kworker/4:1H", pid 131, jiffies 4295062972 (age 1269.720s)
  hex dump (first 8 bytes):
    62 6c 61 00 6b 6b 6b a5                          bla.kkk.
  backtrace:
    [&lt;000000004447d253&gt;] kstrdup+0x2e/0x60
    [&lt;0000000047259793&gt;] kobject_set_name_vargs+0x2f/0xb0
    [&lt;00000000c2ee3bc8&gt;] dev_set_name+0xab/0xe0
    [&lt;000000002b6bdfb1&gt;] rtrs_srv_create_sess_files+0x260/0x290 [rtrs_server]
    [&lt;0000000075d87bd7&gt;] rtrs_srv_info_req_done+0x71b/0x960 [rtrs_server]
    [&lt;00000000ccdf1bb5&gt;] __ib_process_cq+0x94/0x100 [ib_core]
    [&lt;00000000cbcb60cb&gt;] ib_cq_poll_work+0x32/0xc0 [ib_core]
    [&lt;000000002b53eaa1&gt;] process_one_work+0x4bc/0x980
    [&lt;00000000da3499fb&gt;] worker_thread+0x78/0x5c0
    [&lt;00000000167127a4&gt;] kthread+0x191/0x1e0
    [&lt;0000000060802104&gt;] ret_from_fork+0x3a/0x50
unreferenced object 0xffff88806d6bb100 (size 256):
  comm "kworker/4:1H", pid 131, jiffies 4295062972 (age 1269.720s)
  hex dump (first 32 bytes):
    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
    ff ff ff ff ff ff ff ff 00 59 4d 86 ff ff ff ff  .........YM.....
  backtrace:
    [&lt;00000000a18a11e4&gt;] device_add+0x74d/0xa00
    [&lt;00000000a915b95f&gt;] rtrs_srv_create_sess_files.cold+0x49/0x1fe [rtrs_server]
    [&lt;0000000075d87bd7&gt;] rtrs_srv_info_req_done+0x71b/0x960 [rtrs_server]
    [&lt;00000000ccdf1bb5&gt;] __ib_process_cq+0x94/0x100 [ib_core]
    [&lt;00000000cbcb60cb&gt;] ib_cq_poll_work+0x32/0xc0 [ib_core]
    [&lt;000000002b53eaa1&gt;] process_one_work+0x4bc/0x980
    [&lt;00000000da3499fb&gt;] worker_thread+0x78/0x5c0
    [&lt;00000000167127a4&gt;] kthread+0x191/0x1e0
    [&lt;0000000060802104&gt;] ret_from_fork+0x3a/0x50

The problem is we increase device refcount by get_device in process_info_req
for each path, but only does put_deice for last path, which lead to
memory leak.

To fix it, it also calls put_device when dev_ref is not 0.

Fixes: e2853c49477d1 ("RDMA/rtrs-srv-sysfs: fix missing put_device")
Link: https://lore.kernel.org/r/20210528113018.52290-19-jinpu.wang@ionos.com
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/rtrs-srv: Fix memory leak of unfreed rtrs_srv_stats object</title>
<updated>2021-07-14T14:56:18+00:00</updated>
<author>
<name>Gioh Kim</name>
<email>gi-oh.kim@cloud.ionos.com</email>
</author>
<published>2021-05-28T11:30:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e7df73088443c84d82d1fe02495cf811ddc871c1'/>
<id>e7df73088443c84d82d1fe02495cf811ddc871c1</id>
<content type='text'>
[ Upstream commit 2371c40354509746e4a4dad09a752e027a30f148 ]

When closing a session, currently the rtrs_srv_stats object in the
closing session is freed by kobject release. But if it failed
to create a session by various reasons, it must free the rtrs_srv_stats
object directly because kobject is not created yet.

This problem is found by kmemleak as below:

1. One client machine maps /dev/nullb0 with session name 'bla':
root@test1:~# echo "sessname=bla path=ip:192.168.122.190 \
device_path=/dev/nullb0" &gt; /sys/devices/virtual/rnbd-client/ctl/map_device

2. Another machine failed to create a session with the same name 'bla':
root@test2:~# echo "sessname=bla path=ip:192.168.122.190 \
device_path=/dev/nullb1" &gt; /sys/devices/virtual/rnbd-client/ctl/map_device
-bash: echo: write error: Connection reset by peer

3. The kmemleak on server machine reported an error:
unreferenced object 0xffff888033cdc800 (size 128):
  comm "kworker/2:1", pid 83, jiffies 4295086585 (age 2508.680s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;00000000a72903b2&gt;] __alloc_sess+0x1d4/0x1250 [rtrs_server]
    [&lt;00000000d1e5321e&gt;] rtrs_srv_rdma_cm_handler+0xc31/0xde0 [rtrs_server]
    [&lt;00000000bb2f6e7e&gt;] cma_ib_req_handler+0xdc5/0x2b50 [rdma_cm]
    [&lt;00000000e896235d&gt;] cm_process_work+0x2d/0x100 [ib_cm]
    [&lt;00000000b6866c5f&gt;] cm_req_handler+0x11bc/0x1c40 [ib_cm]
    [&lt;000000005f5dd9aa&gt;] cm_work_handler+0xe65/0x3cf2 [ib_cm]
    [&lt;00000000610151e7&gt;] process_one_work+0x4bc/0x980
    [&lt;00000000541e0f77&gt;] worker_thread+0x78/0x5c0
    [&lt;00000000423898ca&gt;] kthread+0x191/0x1e0
    [&lt;000000005a24b239&gt;] ret_from_fork+0x3a/0x50

Fixes: 39c2d639ca183 ("RDMA/rtrs-srv: Set .release function for rtrs srv device during device init")
Link: https://lore.kernel.org/r/20210528113018.52290-18-jinpu.wang@ionos.com
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Md Haris Iqbal &lt;haris.iqbal@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2371c40354509746e4a4dad09a752e027a30f148 ]

When closing a session, currently the rtrs_srv_stats object in the
closing session is freed by kobject release. But if it failed
to create a session by various reasons, it must free the rtrs_srv_stats
object directly because kobject is not created yet.

This problem is found by kmemleak as below:

1. One client machine maps /dev/nullb0 with session name 'bla':
root@test1:~# echo "sessname=bla path=ip:192.168.122.190 \
device_path=/dev/nullb0" &gt; /sys/devices/virtual/rnbd-client/ctl/map_device

2. Another machine failed to create a session with the same name 'bla':
root@test2:~# echo "sessname=bla path=ip:192.168.122.190 \
device_path=/dev/nullb1" &gt; /sys/devices/virtual/rnbd-client/ctl/map_device
-bash: echo: write error: Connection reset by peer

3. The kmemleak on server machine reported an error:
unreferenced object 0xffff888033cdc800 (size 128):
  comm "kworker/2:1", pid 83, jiffies 4295086585 (age 2508.680s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;00000000a72903b2&gt;] __alloc_sess+0x1d4/0x1250 [rtrs_server]
    [&lt;00000000d1e5321e&gt;] rtrs_srv_rdma_cm_handler+0xc31/0xde0 [rtrs_server]
    [&lt;00000000bb2f6e7e&gt;] cma_ib_req_handler+0xdc5/0x2b50 [rdma_cm]
    [&lt;00000000e896235d&gt;] cm_process_work+0x2d/0x100 [ib_cm]
    [&lt;00000000b6866c5f&gt;] cm_req_handler+0x11bc/0x1c40 [ib_cm]
    [&lt;000000005f5dd9aa&gt;] cm_work_handler+0xe65/0x3cf2 [ib_cm]
    [&lt;00000000610151e7&gt;] process_one_work+0x4bc/0x980
    [&lt;00000000541e0f77&gt;] worker_thread+0x78/0x5c0
    [&lt;00000000423898ca&gt;] kthread+0x191/0x1e0
    [&lt;000000005a24b239&gt;] ret_from_fork+0x3a/0x50

Fixes: 39c2d639ca183 ("RDMA/rtrs-srv: Set .release function for rtrs srv device during device init")
Link: https://lore.kernel.org/r/20210528113018.52290-18-jinpu.wang@ionos.com
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Md Haris Iqbal &lt;haris.iqbal@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/rtrs: Do not reset hb_missed_max after re-connection</title>
<updated>2021-07-14T14:56:18+00:00</updated>
<author>
<name>Gioh Kim</name>
<email>gi-oh.kim@cloud.ionos.com</email>
</author>
<published>2021-05-28T11:30:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f03d4c12965e1ce454f02572268c9a849fc593b8'/>
<id>f03d4c12965e1ce454f02572268c9a849fc593b8</id>
<content type='text'>
[ Upstream commit 64bce1ee978491a779eb31098b21c57d4e431d6a ]

When re-connecting, it resets hb_missed_max to 0.
Before the first re-connecting, client will trigger re-connection
when it gets hb-ack more than 5 times. But after the first
re-connecting, clients will do re-connection whenever it does
not get hb-ack because hb_missed_max is 0.

There is no need to reset hb_missed_max when re-connecting.
hb_missed_max should be kept until closing the session.

Fixes: c0894b3ea69d3 ("RDMA/rtrs: core: lib functions shared between client and server modules")
Link: https://lore.kernel.org/r/20210528113018.52290-16-jinpu.wang@ionos.com
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 64bce1ee978491a779eb31098b21c57d4e431d6a ]

When re-connecting, it resets hb_missed_max to 0.
Before the first re-connecting, client will trigger re-connection
when it gets hb-ack more than 5 times. But after the first
re-connecting, clients will do re-connection whenever it does
not get hb-ack because hb_missed_max is 0.

There is no need to reset hb_missed_max when re-connecting.
hb_missed_max should be kept until closing the session.

Fixes: c0894b3ea69d3 ("RDMA/rtrs: core: lib functions shared between client and server modules")
Link: https://lore.kernel.org/r/20210528113018.52290-16-jinpu.wang@ionos.com
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its stats</title>
<updated>2021-07-14T14:56:17+00:00</updated>
<author>
<name>Md Haris Iqbal</name>
<email>haris.iqbal@cloud.ionos.com</email>
</author>
<published>2021-05-28T11:30:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bd4df557aeefe2853ca6dd81af484a1e8902d5dd'/>
<id>bd4df557aeefe2853ca6dd81af484a1e8902d5dd</id>
<content type='text'>
[ Upstream commit 41db63a7efe1c8c2dd282c1849a6ebfbbedbaf67 ]

When get_next_path_min_inflight is called to select the next path, it
iterates over the list of available rtrs_clt_sess (paths). It then reads
the number of inflight IOs for that path to select one which has the least
inflight IO.

But it may so happen that rtrs_clt_sess (path) is no longer in the
connected state because closing or error recovery paths can change the status
of the rtrs_clt_Sess.

For example, the client sent the heart-beat and did not get the
response, it would change the session status and stop IO processing.
The added checking of this patch can prevent accessing the broken path
and generating duplicated error messages.

It is ok if the status is changed after checking the status because
the error recovery path does not free memory and only tries to
reconnection. And also it is ok if the session is closed after checking
the status because closing the session changes the session status and
flush all IO beforing free memory. If the session is being accessed for
IO processing, the closing session will wait.

Fixes: 6a98d71daea18 ("RDMA/rtrs: client: main functionality")
Link: https://lore.kernel.org/r/20210528113018.52290-13-jinpu.wang@ionos.com
Signed-off-by: Md Haris Iqbal &lt;haris.iqbal@ionos.com&gt;
Reviewed-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 41db63a7efe1c8c2dd282c1849a6ebfbbedbaf67 ]

When get_next_path_min_inflight is called to select the next path, it
iterates over the list of available rtrs_clt_sess (paths). It then reads
the number of inflight IOs for that path to select one which has the least
inflight IO.

But it may so happen that rtrs_clt_sess (path) is no longer in the
connected state because closing or error recovery paths can change the status
of the rtrs_clt_Sess.

For example, the client sent the heart-beat and did not get the
response, it would change the session status and stop IO processing.
The added checking of this patch can prevent accessing the broken path
and generating duplicated error messages.

It is ok if the status is changed after checking the status because
the error recovery path does not free memory and only tries to
reconnection. And also it is ok if the session is closed after checking
the status because closing the session changes the session status and
flush all IO beforing free memory. If the session is being accessed for
IO processing, the closing session will wait.

Fixes: 6a98d71daea18 ("RDMA/rtrs: client: main functionality")
Link: https://lore.kernel.org/r/20210528113018.52290-13-jinpu.wang@ionos.com
Signed-off-by: Md Haris Iqbal &lt;haris.iqbal@ionos.com&gt;
Reviewed-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Gioh Kim &lt;gi-oh.kim@ionos.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/srp: Fix a recently introduced memory leak</title>
<updated>2021-07-14T14:56:17+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2021-05-24T04:12:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=067b6631315ded7c34817403ca35732888d749a1'/>
<id>067b6631315ded7c34817403ca35732888d749a1</id>
<content type='text'>
[ Upstream commit 7ec2e27a3afff64c96bfe7a77685c33619db84be ]

Only allocate a memory registration list if it will be used and if it will
be freed.

Link: https://lore.kernel.org/r/20210524041211.9480-5-bvanassche@acm.org
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Fixes: f273ad4f8d90 ("RDMA/srp: Remove support for FMR memory registration")
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7ec2e27a3afff64c96bfe7a77685c33619db84be ]

Only allocate a memory registration list if it will be used and if it will
be freed.

Link: https://lore.kernel.org/r/20210524041211.9480-5-bvanassche@acm.org
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Fixes: f273ad4f8d90 ("RDMA/srp: Remove support for FMR memory registration")
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
