lkml.org 
[lkml]   [2022]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] mm: Re-allow pinning of zero pfns
    On Sat, Jun 11, 2022 at 08:29:47PM +0200, David Hildenbrand wrote:
    > On 11.06.22 00:35, Alex Williamson wrote:
    > > The commit referenced below subtly and inadvertently changed the logic
    > > to disallow pinning of zero pfns. This breaks device assignment with
    > > vfio and potentially various other users of gup. Exclude the zero page
    > > test from the negation.
    >
    > I wonder which setups can reliably work with a long-term pin on a shared
    > zeropage. In a MAP_PRIVATE mapping, any write access via the page tables
    > will end up replacing the shared zeropage with an anonymous page.
    > Something similar should apply in MAP_SHARED mappings, when lazily
    > allocating disk blocks.
    >
    > In the future, we might trigger unsharing when taking a R/O pin for the
    > shared zeropage, just like we do as of now upstream for shared anonymous
    > pages (!PageAnonExclusive). And something similar could then be done
    > when finding a !anon page in a MAP_SHARED mapping.

    I'm also confused how qemu is hitting this and it isn't already a bug?

    It is arising because vfio doesn't use FOLL_FORCE|FOLL_WRITE to move
    away the zero page in most cases.

    And why does Yishai say it causes an infinite loop in the kernel?

    Jason

    \
     
     \ /
      Last update: 2022-06-15 17:58    [W:3.123 / U:0.472 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site