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 <>
To:     Leon Romanovsky <>
        Moni Shoua <>
Subject: Re: [net-next][PATCH v2 2/2] rds: add sysctl for rds support of

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 <>
>>>>>> Reviewed-tested-by: Zhu Yanjun <>
>>>>>> Signed-off-by: Hans Westgaard Ry <>
>>>>>> Signed-off-by: Santosh Shilimkar <>
>>>>>> ---
>>>>>>     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.

Powered by blists - more mailing lists