[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <238e5d3c-30e8-86fc-0263-42864fd0d848@cn.fujitsu.com>
Date: Sat, 28 Aug 2021 16:42:52 +0800
From: "Li, Zhijian" <lizhijian@...fujitsu.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Leon Romanovsky <leon@...nel.org>,
"dledford@...hat.com" <dledford@...hat.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] RDMA/mlx5: return the EFAULT per ibv_advise_mr(3)
Just noticed that there is another code path i was missing will return EINVAL
when get_prefetchable_mr returns NULL
ENOENT:
mlx5_ib_advise_mr_prefetch()
-> mlx5_ib_prefetch_sg_list()
-> get_prefetchable_mr()
return -ENOENT;
EINVAL:
mlx5_ib_advise_mr_prefetch
->init_prefetch_work()
-> get_prefetchable_mr()
return -EINVAL;
where get_prefetchable_mr will check pd and write access & key
So which value we should return ?
Thanks
on 2021/8/26 9:18, Li, Zhijian wrote:
>
> On 26/08/2021 01:28, Jason Gunthorpe wrote:
>> On Sat, Aug 21, 2021 at 05:44:43PM +0800, Li, Zhijian wrote:
>>> convert to text and send again
>>>
>>>
>>> Hi Jason & Leon
>>>
>>> It reminds me that ibv_advise_mr doesn't mention ENOENT any more which value the API actually returns now.
>>> the ENOENT cases/situations returned by kernel mlx5 implementation is most likely same with EINVALL as its manpage[1].
>>>
>>> So shall we return EINVAL instead of ENOENT in kernel side when get_prefetchable_mr returns NULL?
>> No, the man page should be fixed
> thanks a lot, i have submitted a RP to rdma-core https://github.com/linux-rdma/rdma-core/pull/1048
>
> Thanks
> Zhijian
>
>> Jason
>>
>>
Powered by blists - more mailing lists