linux-kernel - Re: [RFC][PATCH v2 1/5] mm: Avoid unmapping pinned pages

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: <20220121114058.GE20638@worktop.programming.kicks-ass.net>
Date:   Fri, 21 Jan 2022 12:40:58 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     David Hildenbrand <david@...hat.com>
Cc:     mingo@...hat.com, tglx@...utronix.de, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
        bristot@...hat.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-api@...r.kernel.org, x86@...nel.org,
        pjt@...gle.com, posk@...gle.com, avagin@...gle.com,
        jannh@...gle.com, tdelisle@...terloo.ca, mark.rutland@....com,
        posk@...k.io
Subject: Re: [RFC][PATCH v2 1/5] mm: Avoid unmapping pinned pages

On Fri, Jan 21, 2022 at 10:04:45AM +0100, David Hildenbrand wrote:
> On 21.01.22 09:59, Peter Zijlstra wrote:

> > However, I'm not quite sure what fork() does with pages that have a pin.
> 
> We COW the anon pages always, and we protect against concurrent GUP
> using the
> * mmap_lock in exclusive mode for ordinary GUP
> * mm->write_protect_seq for GUP-fast

Right, but neither the mmap_sem nor the write_protect_seq help anything
at all vs already extant page pins.

But I just found copy_present_page()'s page_needs_cow_for_dma(), which I
think deals with exactly that case, it avoids doing CoW on pinned pages
and instead feeds the child a full copy while keeping the pinned page in
the original process.

> > Naively, a page that has async DMA activity should not be CoW'ed, or if
> > it is, care must be taken to ensure the original pages stays in the
> > original process, but I realize that's somewhat hard.
> 
> That's precisely what I'm working on fixing ... and yes, it's hard.
> 
> Let me know if you need any other information, I've spent way too much
> time on this than I ever panned.

So let me try and get this right:

 - GUP post-fork breaks CoW for FOLL_WRITE/FOLL_PIN, without either
   there's a problem where one task might observe changes by another.

 - GUP pre-fork prevents CoW and does a full copy.

And that all mostly works, except for a fair amount of 'fun' cases?