<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/infiniband/hw/hns, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/infiniband/hw/hns?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/infiniband/hw/hns?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-10-24T12:01:57Z</updated>
<entry>
<title>RDMA/hns: Fix NULL pointer problem in free_mr_init()</title>
<updated>2022-10-24T12:01:57Z</updated>
<author>
<name>Yixing Liu</name>
<email>liuyixing1@huawei.com</email>
</author>
<published>2022-10-24T08:38:14Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=12bcaf87d8b66d8cd812479c8a6349dcb245375c'/>
<id>urn:sha1:12bcaf87d8b66d8cd812479c8a6349dcb245375c</id>
<content type='text'>
Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL
pointer.  It should be init mutex_init() first before use the lock.

  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
  Call trace:
   __mutex_lock.constprop.0+0xd0/0x5c0
   __mutex_lock_slowpath+0x1c/0x2c
   mutex_lock+0x44/0x50
   free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2]
   hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2]
   hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2]
   ib_dereg_mr_user+0x54/0x124
   uverbs_free_mr+0x24/0x30
   destroy_hw_idr_uobject+0x38/0x74
   uverbs_destroy_uobject+0x48/0x1c4
   uobj_destroy+0x74/0xcc
   ib_uverbs_cmd_verbs+0x368/0xbb0
   ib_uverbs_ioctl+0xec/0x1a4
   __arm64_sys_ioctl+0xb4/0x100
   invoke_syscall+0x50/0x120
   el0_svc_common.constprop.0+0x58/0x190
   do_el0_svc+0x30/0x90
   el0_svc+0x2c/0xb4
   el0t_64_sync_handler+0x1a4/0x1b0
   el0t_64_sync+0x19c/0x1a0

Fixes: 70f92521584f ("RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPT")
Signed-off-by: Yixing Liu &lt;liuyixing1@huawei.com&gt;
Signed-off-by: Haoyue Xu &lt;xuhaoyue1@hisilicon.com&gt;
Link: https://lore.kernel.org/r/20221024083814.1089722-3-xuhaoyue1@hisilicon.com
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/hns: Disable local invalidate operation</title>
<updated>2022-10-24T12:01:57Z</updated>
<author>
<name>Yangyang Li</name>
<email>liyangyang20@huawei.com</email>
</author>
<published>2022-10-24T08:38:13Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=9e272ed69ad6f6952fafd0599d6993575512408e'/>
<id>urn:sha1:9e272ed69ad6f6952fafd0599d6993575512408e</id>
<content type='text'>
When function reset and local invalidate are mixed, HNS RoCEE may hang.
Before introducing the cause of the problem, two hardware internal
concepts need to be introduced:

    1. Execution queue: The queue of hardware execution instructions,
    function reset and local invalidate are queued for execution in this
    queue.

    2.Local queue: A queue that stores local operation instructions. The
    instructions in the local queue will be sent to the execution queue
    for execution. The instructions in the local queue will not be removed
    until the execution is completed.

The reason for the problem is as follows:

    1. There is a function reset instruction in the execution queue, which
    is currently being executed. A necessary condition for the successful
    execution of function reset is: the hardware pipeline needs to empty
    the instructions that were not completed before;

    2. A local invalidate instruction at the head of the local queue is
    sent to the execution queue. Now there are two instructions in the
    execution queue, the first is the function reset instruction, and the
    second is the local invalidate instruction, which will be executed in
    se quence;

    3. The user has issued many local invalidate operations, causing the
    local queue to be filled up.

    4. The user still has a new local operation command and is queuing to
    enter the local queue. But the local queue is full and cannot receive
    new instructions, this instruction is temporarily stored at the
    hardware pipeline.

    5. The function reset has been waiting for the instruction before the
    hardware pipeline stage is drained. The hardware pipeline stage also
    caches a local invalidate instruction, so the function reset cannot be
    completed, and the instructions after it cannot be executed.

These factors together cause the execution logic deadlock of the hardware,
and the consequence is that RoCEE will not have any response.  Considering
that the local operation command may potentially cause RoCEE to hang, this
feature is no longer supported.

Fixes: e93df0108579 ("RDMA/hns: Support local invalidate for hip08 in kernel space")
Signed-off-by: Yangyang Li &lt;liyangyang20@huawei.com&gt;
Signed-off-by: Wenpeng Liang &lt;liangwenpeng@huawei.com&gt;
Signed-off-by: Haoyue Xu &lt;xuhaoyue1@hisilicon.com&gt;
Link: https://lore.kernel.org/r/20221024083814.1089722-2-xuhaoyue1@hisilicon.com
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>treewide: use prandom_u32_max() when possible, part 1</title>
<updated>2022-10-11T23:42:55Z</updated>
<author>
<name>Jason A. Donenfeld</name>
<email>Jason@zx2c4.com</email>
</author>
<published>2022-10-05T14:43:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=81895a65ec63ee1daec3255dc1a06675d2fbe915'/>
<id>urn:sha1:81895a65ec63ee1daec3255dc1a06675d2fbe915</id>
<content type='text'>
Rather than incurring a division or requesting too many random bytes for
the given range, use the prandom_u32_max() function, which only takes
the minimum required bytes from the RNG and avoids divisions. This was
done mechanically with this coccinelle script:

@basic@
expression E;
type T;
identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32";
typedef u64;
@@
(
- ((T)get_random_u32() % (E))
+ prandom_u32_max(E)
|
- ((T)get_random_u32() &amp; ((E) - 1))
+ prandom_u32_max(E * XXX_MAKE_SURE_E_IS_POW2)
|
- ((u64)(E) * get_random_u32() &gt;&gt; 32)
+ prandom_u32_max(E)
|
- ((T)get_random_u32() &amp; ~PAGE_MASK)
+ prandom_u32_max(PAGE_SIZE)
)

@multi_line@
identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32";
identifier RAND;
expression E;
@@

-       RAND = get_random_u32();
        ... when != RAND
-       RAND %= (E);
+       RAND = prandom_u32_max(E);

// Find a potential literal
@literal_mask@
expression LITERAL;
type T;
identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32";
position p;
@@

        ((T)get_random_u32()@p &amp; (LITERAL))

// Add one to the literal.
@script:python add_one@
literal &lt;&lt; literal_mask.LITERAL;
RESULT;
@@

value = None
if literal.startswith('0x'):
        value = int(literal, 16)
elif literal[0] in '123456789':
        value = int(literal, 10)
if value is None:
        print("I don't know how to handle %s" % (literal))
        cocci.include_match(False)
elif value == 2**32 - 1 or value == 2**31 - 1 or value == 2**24 - 1 or value == 2**16 - 1 or value == 2**8 - 1:
        print("Skipping 0x%x for cleanup elsewhere" % (value))
        cocci.include_match(False)
elif value &amp; (value + 1) != 0:
        print("Skipping 0x%x because it's not a power of two minus one" % (value))
        cocci.include_match(False)
elif literal.startswith('0x'):
        coccinelle.RESULT = cocci.make_expr("0x%x" % (value + 1))
else:
        coccinelle.RESULT = cocci.make_expr("%d" % (value + 1))

// Replace the literal mask with the calculated result.
@plus_one@
expression literal_mask.LITERAL;
position literal_mask.p;
expression add_one.RESULT;
identifier FUNC;
@@

-       (FUNC()@p &amp; (LITERAL))
+       prandom_u32_max(RESULT)

@collapse_ret@
type T;
identifier VAR;
expression E;
@@

 {
-       T VAR;
-       VAR = (E);
-       return VAR;
+       return E;
 }

@drop_var@
type T;
identifier VAR;
@@

 {
-       T VAR;
        ... when != VAR
 }

Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Yury Norov &lt;yury.norov@gmail.com&gt;
Reviewed-by: KP Singh &lt;kpsingh@kernel.org&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt; # for ext4 and sbitmap
Reviewed-by: Christoph Böhmwalder &lt;christoph.boehmwalder@linbit.com&gt; # for drbd
Acked-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Acked-by: Heiko Carstens &lt;hca@linux.ibm.com&gt; # for s390
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt; # for mmc
Acked-by: Darrick J. Wong &lt;djwong@kernel.org&gt; # for xfs
Signed-off-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'v6.0' into rdma.git for-next</title>
<updated>2022-10-06T22:48:45Z</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgg@nvidia.com</email>
</author>
<published>2022-10-06T22:47:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=33331a728c83f380e53a3dbf2be0c1893da1d739'/>
<id>urn:sha1:33331a728c83f380e53a3dbf2be0c1893da1d739</id>
<content type='text'>
Trvial merge conflicts against rdma.git for-rc resolved matching
linux-next:
            drivers/infiniband/hw/hns/hns_roce_hw_v2.c
            drivers/infiniband/hw/hns/hns_roce_main.c

https://lore.kernel.org/r/20220929124005.105149-1-broonie@kernel.org

Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/hns: Unified Log Printing Style</title>
<updated>2022-09-27T13:15:25Z</updated>
<author>
<name>Guofeng Yue</name>
<email>yueguofeng@hisilicon.com</email>
</author>
<published>2022-09-22T12:33:15Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=f0588567976edcb6a7f6f20a9126b40e4d2da818'/>
<id>urn:sha1:f0588567976edcb6a7f6f20a9126b40e4d2da818</id>
<content type='text'>
The first letter of the log information is changed to lowercase
to keep the same style.

Link: https://lore.kernel.org/r/20220922123315.3732205-13-xuhaoyue1@hisilicon.com
Signed-off-by: Guofeng Yue &lt;yueguofeng@hisilicon.com&gt;
Signed-off-by: Haoyue Xu &lt;xuhaoyue1@hisilicon.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/hns: Replacing magic number with macros in apply_func_caps()</title>
<updated>2022-09-27T13:15:25Z</updated>
<author>
<name>Yixing Liu</name>
<email>liuyixing1@huawei.com</email>
</author>
<published>2022-09-22T12:33:14Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8c581c47b9ba064cc3c3ad399081c202b0b0bf78'/>
<id>urn:sha1:8c581c47b9ba064cc3c3ad399081c202b0b0bf78</id>
<content type='text'>
Replacing magic number with macros in function apply_func_caps().

Link: https://lore.kernel.org/r/20220922123315.3732205-12-xuhaoyue1@hisilicon.com
Signed-off-by: Yixing Liu &lt;liuyixing1@huawei.com&gt;
Signed-off-by: Haoyue Xu &lt;xuhaoyue1@hisilicon.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/hns: Repacing 'dseg_len' by macros in fill_ext_sge_inl_data()</title>
<updated>2022-09-27T13:15:25Z</updated>
<author>
<name>Luoyouming</name>
<email>luoyouming@huawei.com</email>
</author>
<published>2022-09-22T12:33:13Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3b1f864c904915b3baebffb31ea05ee704b0df3c'/>
<id>urn:sha1:3b1f864c904915b3baebffb31ea05ee704b0df3c</id>
<content type='text'>
The sge size is known to be constant, so it's unnecessary to use sizeof to
calculate.

Link: https://lore.kernel.org/r/20220922123315.3732205-11-xuhaoyue1@hisilicon.com
Signed-off-by: Luoyouming &lt;luoyouming@huawei.com&gt;
Signed-off-by: Haoyue Xu &lt;xuhaoyue1@hisilicon.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/hns: Remove redundant 'max_srq_desc_sz' in caps</title>
<updated>2022-09-27T13:15:25Z</updated>
<author>
<name>Yangyang Li</name>
<email>liyangyang20@huawei.com</email>
</author>
<published>2022-09-22T12:33:12Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=6649b4a1c43c6ad153c3ff0c1754a436aa6b6390'/>
<id>urn:sha1:6649b4a1c43c6ad153c3ff0c1754a436aa6b6390</id>
<content type='text'>
The max_srq_desc_sz is defined in the code, but never used,
so delete this redundant variable.

Link: https://lore.kernel.org/r/20220922123315.3732205-10-xuhaoyue1@hisilicon.com
Signed-off-by: Yangyang Li &lt;liyangyang20@huawei.com&gt;
Signed-off-by: Haoyue Xu &lt;xuhaoyue1@hisilicon.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/hns: Remove redundant 'num_mtt_segs' and 'max_extend_sg'</title>
<updated>2022-09-27T13:15:25Z</updated>
<author>
<name>Yangyang Li</name>
<email>liyangyang20@huawei.com</email>
</author>
<published>2022-09-22T12:33:11Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=5436272c8cf4eb420fdb3926ec07560051c8fd11'/>
<id>urn:sha1:5436272c8cf4eb420fdb3926ec07560051c8fd11</id>
<content type='text'>
The num_mtt_segs and max_extend_sg used to be used for HIP06,
remove them since the HIP06 code has been removed.

Link: https://lore.kernel.org/r/20220922123315.3732205-9-xuhaoyue1@hisilicon.com
Signed-off-by: Yangyang Li &lt;liyangyang20@huawei.com&gt;
Signed-off-by: Haoyue Xu &lt;xuhaoyue1@hisilicon.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/hns: Remove redundant 'phy_addr' in hns_roce_hem_list_find_mtt()</title>
<updated>2022-09-27T13:15:25Z</updated>
<author>
<name>Chengchang Tang</name>
<email>tangchengchang@huawei.com</email>
</author>
<published>2022-09-22T12:33:10Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=5f652387c5423a82453c5cb446a88834bf41a94b'/>
<id>urn:sha1:5f652387c5423a82453c5cb446a88834bf41a94b</id>
<content type='text'>
This parameter has never been used. Remove it to simplify the function.

Link: https://lore.kernel.org/r/20220922123315.3732205-8-xuhaoyue1@hisilicon.com
Signed-off-by: Chengchang Tang &lt;tangchengchang@huawei.com&gt;
Signed-off-by: Yunsheng Lin &lt;linyunsheng@huawei.com&gt;
Signed-off-by: Haoyue Xu &lt;xuhaoyue1@hisilicon.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
</feed>
