linux-kernel - Re: [PATCH 2/2] mm/frame-vec: use FOLL

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 linux-cve-announce 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]

Message-ID: <f5130c7f-eebe-7b21-62b8-68f08212b106@nvidia.com>
Date:   Sat, 3 Oct 2020 15:52:32 -0700
From:   John Hubbard <jhubbard@...dia.com>
To:     Daniel Vetter <daniel.vetter@...ll.ch>
CC:     DRI Development <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jérôme Glisse <jglisse@...hat.com>,
        Jan Kara <jack@...e.cz>,
        Dan Williams <dan.j.williams@...el.com>,
        Linux MM <linux-mm@...ck.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        "open list:DMA BUFFER SHARING FRAMEWORK" 
        <linux-media@...r.kernel.org>
Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM

On 10/3/20 2:45 AM, Daniel Vetter wrote:
> On Sat, Oct 3, 2020 at 12:39 AM John Hubbard <jhubbard@...dia.com> wrote:
>>
>> On 10/2/20 10:53 AM, Daniel Vetter wrote:
>>> For $reasons I've stumbled over this code and I'm not sure the change
>>> to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
>>> convert get_user_pages() --> pin_user_pages()") was entirely correct.
>>>
>>> This here is used for long term buffers (not just quick I/O) like
>>> RDMA, and John notes this in his patch. But I thought the rule for
>>> these is that they need to add FOLL_LONGTERM, which John's patch
>>> didn't do.
>>
>> Yep. The earlier gup --> pup conversion patches were intended to not
>> have any noticeable behavior changes, and FOLL_LONGTERM, with it's
>> special cases and such, added some risk that I wasn't ready to take
>> on yet. Also, FOLL_LONGTERM rules are only *recently* getting firmed
>> up. So there was some doubt at least in my mind, about which sites
>> should have it.
>>
>> But now that we're here, I think it's really good that you've brought
>> this up. It's definitely time to add FOLL_LONGTERM wherever it's missing.
> 
> So should I keep this patch, or will it collide with a series you're working on?

It doesn't collide with anything on my end yet, because I've been slow to
pick up on the need for changing callsites to add FOLL_LONGTERM. :)

And it looks like that's actually a problem, because:

> 
> Also with the firmed up rules, correct that I can also drop the
> vma_is_fsdax check when the FOLL_LONGTERM flag is set?

That's the right direction to go *in general*, but I see that the
pin_user_pages code is still a bit stuck in the past. And this patch
won't actually work, with or without that vma_is_fsdax() check.
Because:

get_vaddr_frames(FOLL_LONGTERM)
    pin_user_pages_locked()
	if (WARN_ON_ONCE(gup_flags & FOLL_LONGTERM))
		return -EINVAL;


So, again, pin_user_pages*() is at least partly behind the times here.
I can jump in and start fixing it up, but it depends on what you and
Oded and others are planning? Note: there is a particular combination of
dax and locking that we have to still avoid, within gup.c. That's
already covered, but needs to continue to be covered when we enable
FOLL_LONGTERM in the remaining pin_user_pages*() calling paths.



thanks,
-- 
John Hubbard
NVIDIA