netdev - Re: [net-next][PATCH v2 2/2] rds: add sysctl for rds support of On-Demand-Paging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 May 2019 09:37:48 -0700
From:   Santosh Shilimkar <santosh.shilimkar@...cle.com>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        Moni Shoua <monis@...lanox.com>
Subject: Re: [net-next][PATCH v2 2/2] rds: add sysctl for rds support of
 On-Demand-Paging

5/4/2019 11:22 PM, Leon Romanovsky wrote:
> On Thu, May 02, 2019 at 10:59:58AM -0700, Santosh Shilimkar wrote:
>>
>>
>> On 5/1/2019 11:18 PM, Leon Romanovsky wrote:
>>> On Wed, May 01, 2019 at 10:54:50AM -0700, Santosh Shilimkar wrote:
>>>> On 5/1/2019 12:45 AM, Leon Romanovsky wrote:
>>>>> On Mon, Apr 29, 2019 at 04:37:20PM -0700, Santosh Shilimkar wrote:
>>>>>> RDS doesn't support RDMA on memory apertures that require On Demand
>>>>>> Paging (ODP), such as FS DAX memory. A sysctl is added to indicate
>>>>>> whether RDMA requiring ODP is supported.
>>>>>>
>>>>>> Reviewed-by: H??kon Bugge <haakon.bugge@...cle.com>
>>>>>> Reviewed-tested-by: Zhu Yanjun <yanjun.zhu@...cle.com>
>>>>>> Signed-off-by: Hans Westgaard Ry <hans.westgaard.ry@...cle.com>
>>>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@...cle.com>
>>>>>> ---
>>>>>>     net/rds/ib.h        | 1 +
>>>>>>     net/rds/ib_sysctl.c | 8 ++++++++
>>>>>>     2 files changed, 9 insertions(+)
>>>>>
>>>>> This sysctl is not needed at all
>>>>>
>>>> Its needed for application to check the support of the ODP support
>>>> feature which in progress. Failing the RDS_GET_MR was just one path
>>>> and we also support inline MR registration along with message request.
>>>>
>>>> Basically application runs on different kernel versions and to be
>>>> portable, it will check if underneath RDS support ODP and then only
>>>> use RDMA. If not it will fallback to buffer copy mode. Hope
>>>> it clarifies.
>>>
>>> Using ODP sysctl to determine if to use RDMA or not, looks like very
>>> problematic approach. How old applications will work in such case
>>> without knowledge of such sysctl?
>>> How new applications will distinguish between ODP is not supported, but
>>> RDMA works?
>>>
>> Actually this is not ODP sysctl but really whether RDS supports
>> RDMA on fs_dax memory or not. I had different name for sysctl but
>> in internal review it got changed.
>>
>> Ignoring the name of the sysctl, here is the application logic.
>> - If fs_dax sysctl path doesn't exist, no RDMA on FS DAX memory(this
>> will cover all the older kernels, which doesn't have this patch)
>> - If fs_dax sysctl path exist and its value is 0, no RDMA on FS
>> DAX. This will cover kernels which this patch but don't have
>> actual support for ODP based registration.
>> - If fs_dax sysctl path exist and its value is 1, RDMA can be
>> issued on FS DAX memory. This sysctl will be updated to value 1
>> once the support gets added.
>>
>> Hope it clarifies better now.
> 
> Santosh,
> 
> Thanks for explanation, I have one more question,
> 
> If I'm author of hostile application and write code to disregard that
> new sysctl, will any of combinations of kernel/application cause to
> kernel panic? If not, we don't really need to expose this information,
> if yes, this sysctl is not enough.
> 
It Won't panic. Thats why the other patch also makes the call fail when
tried to register FS DAX memory with RDS.