netdev - Re: [net-next][PATCH v2 1/2] rds: handle unsupported rdma request to fs dax memory

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:   Fri, 10 May 2019 11:58:42 -0700
From:   "santosh.shilimkar@...cle.com" <santosh.shilimkar@...cle.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        Hans Westgaard Ry <hans.westgaard.ry@...cle.com>
Subject: Re: [net-next][PATCH v2 1/2] rds: handle unsupported rdma request to
 fs dax memory

On 5/10/19 11:07 AM, Jason Gunthorpe wrote:
> On Fri, May 10, 2019 at 11:02:35AM -0700, santosh.shilimkar@...cle.com wrote:
>>
>>
>> On 5/10/19 10:55 AM, Jason Gunthorpe wrote:
>>> On Fri, May 10, 2019 at 09:11:24AM -0700, Santosh Shilimkar wrote:
>>>> On 5/10/2019 5:54 AM, Jason Gunthorpe wrote:
>>>>> On Mon, Apr 29, 2019 at 04:37:19PM -0700, Santosh Shilimkar wrote:
>>>>>> From: Hans Westgaard Ry <hans.westgaard.ry@...cle.com>
>>>>>>
>>>>>> RDS doesn't support RDMA on memory apertures that require On Demand
>>>>>> Paging (ODP), such as FS DAX memory. User applications can try to use
>>>>>> RDS to perform RDMA over such memories and since it doesn't report any
>>>>>> failure, it can lead to unexpected issues like memory corruption when
>>>>>> a couple of out of sync file system operations like ftruncate etc. are
>>>>>> performed.
>>>>>
>>>>> This comment doesn't make any sense..
>>>>>
>>>>>> The patch adds a check so that such an attempt to RDMA to/from memory
>>>>>> apertures requiring ODP will fail.
>>>>>>
>>>>>> 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/rdma.c | 5 +++--
>>>>>>     1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>>
[...]

> 
> Why would you need to detect FS DAX memory? GUP users are not supposed
> to care.
> 
> GUP is supposed to work just 'fine' - other than the usual bugs we
> have with GUP and any FS backed memory.
> 
Am not saying there is any issue with GUP. Let me try to explain the
issue first. You are aware of various discussions about doing DMA
or RDMA on FS DAX memory. e.g [1] [2] [3]

One of the proposal to do safely RDMA on FS DAX memory is/was ODP
Since its hooked with mm, it can block file system operations
like ftruncate on the mmaped file systems handle while ongoing IO(RDMA).

Currently RDS doesn't have support for ODP MR registration
and hence we don't want user application to do RDMA using
fastreg/fmr on FS DAX memory which isn't safe. So the intention
was, to make RDS_GET_MR fail if the user provided memory are is
FS DAX & RDS kernel module doesn't support ODP.

We have systems equipped with both regular DRAM as well as PMEM
DIMMs. So RDS needs to find out what kind of memory user is
passing to registers for RDMA. If its regular DRAM, it will
continue as now and return the key to application and if its
FS DAX memory, it  suppose to fail the call. GUP long
term was used since it checked fs dax memory and
reports -EOPNOTSUPP for fs_dax memory. Using that error
code, patch was making RDS get_mr call fail.

In short, till the ODP support added to RDS, we want the RDMA
request to fail for FS dax memory.

Hope above clarifies it.

Regards,
Santosh

[1] https://lwn.net/Articles/737273/
[2] https://lkml.org/lkml/2019/2/5/570
[3] https://lists.01.org/pipermail/linux-nvdimm/2018-January/013935.html