linux-kernel - Re: [PATCH 1/5] mm: Introduce mm_struct.has

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: <6c1292e6-11f0-811c-6cdd-cfc1f4bccbc2@nvidia.com>
Date:   Mon, 28 Sep 2020 17:18:47 -0700
From:   John Hubbard <jhubbard@...dia.com>
To:     Jason Gunthorpe <jgg@...pe.ca>,
        Linus Torvalds <torvalds@...ux-foundation.org>
CC:     Peter Xu <peterx@...hat.com>, Leon Romanovsky <leonro@...dia.com>,
        Linux-MM <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jan Kara <jack@...e.cz>, Michal Hocko <mhocko@...e.com>,
        Kirill Tkhai <ktkhai@...tuozzo.com>,
        Kirill Shutemov <kirill@...temov.name>,
        Hugh Dickins <hughd@...gle.com>,
        Christoph Hellwig <hch@....de>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Oleg Nesterov <oleg@...hat.com>, Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned

On 9/28/20 4:57 PM, Jason Gunthorpe wrote:
> On Mon, Sep 28, 2020 at 12:29:55PM -0700, Linus Torvalds wrote:
...
> I think this is really hard to use and ugly. My thinking has been to
> just stick:
> 
>     if (flags & FOLL_LONGTERM)
>         flags |= FOLL_FORCE | FOLL_WRITE
> 
> In pin_user_pages(). It would make the driver API cleaner. If we can

+1, yes. The other choices so far are, as you say, really difficult to figure
out.

> do a bit better somehow by not COW'ing for certain VMA's as you
> explained then all the better, but not my primary goal..
> 
> Basically, I think if a driver is using FOLL_LONGTERM | FOLL_PIN we
> should guarentee that driver a consistent MM and take the gup_fast
> performance hit to do it.
> 
> AFAICT the giant wack of other cases not using FOLL_LONGTERM really
> shouldn't care about read-decoherence. For those cases the user should
> really not be racing write's with data under read-only pin, and the
> new COW logic looks like it solves the other issues with this.

I hope this doesn't kill the seqcount() idea, though. That was my favorite
part of the discussion, because it neatly separates out the two racing domains
(fork, gup/pup) and allows easy reasoning about them--without really impacting
performance.

Truly elegant. We should go there.

> 
> I know Jann/John have been careful to not have special behaviors for
> the DMA case, but I think it makes sense here. It is actually different.
> 

I think that makes sense. Everyone knew that DMA/FOLL_LONGTERM call sites
were at least potentially special, despite the spirited debates in at least
two conferences about the meaning and implications of "long term". :)

And here we are seeing an example of such a special case, which I think is
natural enough.


thanks,
-- 
John Hubbard
NVIDIA