Re: [PATCH rdma-rc] RDMA/mlx5: Fix dereg mr flow for kernel MRs

[Thorsten Leemhuis]

On 03.01.22 19:26, Leon Romanovsky wrote:
> On Mon, Jan 03, 2022 at 02:15:59PM +0100, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker speaking.
>>
>> On 03.01.22 10:51, Leon Romanovsky wrote:
>>> On Wed, Dec 22, 2021 at 10:51:58AM +0800, Tony Lu wrote:
>>>> On Tue, Dec 21, 2021 at 11:46:41AM +0200, Leon Romanovsky wrote:
>>>>> From: Maor Gottlieb <maorg@xxxxxxxxxx>
>>>>>
>>>>> The cited commit moved umem into the union, hence
>>>>> umem could be accessed only for user MRs. Add udata check
>>>>> before access umem in the dereg flow.
>>>>>
>>>>> Fixes: f0ae4afe3d35 ("RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow")
>>>>> Tested-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
>>>>> Signed-off-by: Maor Gottlieb <maorg@xxxxxxxxxx>
>>>>> Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxx>
>>>>> ---
>>>>>  drivers/infiniband/hw/mlx5/mlx5_ib.h | 2 +-
>>>>>  drivers/infiniband/hw/mlx5/mr.c      | 4 ++--
>>>>>  drivers/infiniband/hw/mlx5/odp.c     | 4 ++--
>>>>>  3 files changed, 5 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
>>>>
>>>> This patch was tested and works for me in our environment for SMC. It
>>>> wouldn't panic when release link and call ib_dereg_mr.
>>>>
>>>> Tested-by: Tony Lu <tonylu@xxxxxxxxxxxxxxxxx>
>>>
>>> Thanks, unfortunately, this patch is incomplete.
>>
>> Could you be a bit more verbose and give a status update? It's hard to
>> follow from the outside. But according to the "Fixes: f0ae4afe3d35"
>> above this was supposed to fix a regression introduced in v5.16-rc5 that
>> was also reported here:
>> https://lore.kernel.org/linux-rdma/9974ea8c-f1cb-aeb4-cf1b-19d37536894a@xxxxxxxxxxxxxxxxx/
> 
> The problematic commit f0ae4afe3d35 ("RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow")
> should be reverted https://lore.kernel.org/all/20211222101312.1358616-1-maorg@xxxxxxxxxx
> and rewritten from the beginning.

Thx for the clarification. Is anyone tasked for sending the revert
upstream, to make sure the revert makes it into 5.16, which is due on
Sunday night?

And someone likely should ensure the change backported to 5.15.y as
e3bc4d4b50cae7db08e50dbe43f771c906e97701 is reverted as well. CCing a
few lists and Greg to make sure everyone is in the loop.

Ciao, Thorsten