On 9/10/21 5:07 PM, Bart Van Assche wrote:
> On 9/10/21 2:47 PM, Bob Pearson wrote:
>> OK I checked out the kernel with the SHA number above and applied the patch series
>> and rebuilt and reinstalled the kernel. I checked out v36.0 of rdma-core and rebuilt
>> that. rdma is version 5.9.0 but I doubt that will have any effect. My startup script
>> is
>>
>> export LD_LIBRARY_PATH=/home/bob/src/rdma-core/build/lib/:/usr/local/lib:/usr/lib
>>
>>
>>
>> sudo ip link set dev enp0s3 mtu 8500
>>
>> sudo ip addr add dev enp0s3 fe80::0a00:27ff:fe94:8a69/64
>>
>> sudo rdma link add rxe0 type rxe netdev enp0s3
>>
>>
>> I am running on a Virtualbox VM instance of Ubuntu 21.04 with 20 cores and 8GB of RAM.
>>
>> The test looks like
>>
>> sudo ./check -q srp/001
>>
>> srp/001 (Create and remove LUNs) [passed]
>>
>> runtime 1.174s ... 1.236s
>>
>> There were no issues.
>>
>> Any guesses what else to look at?
>
> The test I ran is different. I did not run any of the ip link / ip addr /
> rdma link commands since the blktests scripts already run the rdma link
> command. The bug I reported in my previous email is reproducible and
> triggers a VM halt.
>
> Are we using the same kernel config? I attached my kernel config to my
> previous email. The source code location of the crash address is as
> follows:
>
> (gdb) list *(rxe_completer+0x96d)
> 0x228d is in rxe_completer (drivers/infiniband/sw/rxe/rxe_comp.c:149).
> 144 */
> 145 wqe = queue_head(qp->sq.queue, QUEUE_TYPE_FROM_CLIENT);
> 146 *wqe_p = wqe;
> 147
> 148 /* no WQE or requester has not started it yet */
> 149 if (!wqe || wqe->state == wqe_state_posted)
> 150 return pkt ? COMPST_DONE : COMPST_EXIT;
> 151
> 152 /* WQE does not require an ack */
> 153 if (wqe->state == wqe_state_done)
>
> The disassembly output is as follows:
>
> drivers/infiniband/sw/rxe/rxe_comp.c:
> 149 if (!wqe || wqe->state == wqe_state_posted)
> 0x0000000000002277 <+2391>: test %r12,%r12
> 0x000000000000227a <+2394>: je 0x2379 <rxe_completer+2649>
> 0x0000000000002280 <+2400>: lea 0x94(%r12),%rdi
> 0x0000000000002288 <+2408>: call 0x228d <rxe_completer+2413>
> 0x000000000000228d <+2413>: mov 0x94(%r12),%eax
> 0x0000000000002295 <+2421>: test %eax,%eax
> 0x0000000000002297 <+2423>: je 0x237c <rxe_completer+2652>
>
> So the instruction that triggers the crash is "mov 0x94(%r12),%eax".
> Does consumer_addr() perhaps return an invalid address under certain
> circumstances?
>
> Thanks,
>
> Bart.
The most likely cause of this was fixed by a patch submitted 8/20/2021 by Xiao Yang. It is copied here
From: Xiao Yang <yangx.jy@xxxxxxxxxxx>
To: <linux-rdma@xxxxxxxxxxxxxxx>
Cc: <aglo@xxxxxxxxx>, <rpearsonhpe@xxxxxxxxx>, <zyjzyj2000@xxxxxxxxx>,
<jgg@xxxxxxxxxx>, <leon@xxxxxxxxxx>,
Xiao Yang <yangx.jy@xxxxxxxxxxx>
Subject: [PATCH] RDMA/rxe: Zero out index member of struct rxe_queue
Date: Fri, 20 Aug 2021 19:15:09 +0800 [thread overview]
Message-ID: <20210820111509.172500-1-yangx.jy@xxxxxxxxxxx> (raw)
1) New index member of struct rxe_queue is introduced but not zeroed
so the initial value of index may be random.
2) Current index is not masked off to index_mask.
In such case, producer_addr() and consumer_addr() will get an invalid
address by the random index and then accessing the invalid address
triggers the following panic:
"BUG: unable to handle page fault for address: ffff9ae2c07a1414"
Fix the issue by using kzalloc() to zero out index member.
Fixes: 5bcf5a59c41e ("RDMA/rxe: Protext kernel index from user space")
Signed-off-by: Xiao Yang <yangx.jy@xxxxxxxxxxx>
---
drivers/infiniband/sw/rxe/rxe_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/sw/rxe/rxe_queue.c b/drivers/infiniband/sw/rxe/rxe_queue.c
index 85b812586ed4..72d95398e604 100644
--- a/drivers/infiniband/sw/rxe/rxe_queue.c
+++ b/drivers/infiniband/sw/rxe/rxe_queue.c
@@ -63,7 +63,7 @@ struct rxe_queue *rxe_queue_init(struct rxe_dev *rxe, int *num_elem,
if (*num_elem < 0)
goto err1;
- q = kmalloc(sizeof(*q), GFP_KERNEL);
+ q = kzalloc(sizeof(*q), GFP_KERNEL);
if (!q)
goto err1;
--
2.25.1
If kmalloc returns a dirty block of memory you could get random values in the q index which could
easily give a page fault. Once the rxe driver writes a new value it will be masked before storing
and should always be in the allocated buffer. I am not seeing this error perhaps because I am
running in a VM. I just don't know. It should be added to the other fixes.
Bob
