Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <cb7efb0f-5537-5ce4-7aec-bb10ea81d5de@redhat.com>
Date:   Thu, 23 Jun 2022 20:07:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-US
To:     Jason Gunthorpe <jgg@nvidia.com>
Cc:     Alex Williamson <alex.williamson@redhat.com>,
        akpm@linux-foundation.org, minchan@kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, paulmck@kernel.org,
        jhubbard@nvidia.com, joaodias@google.com
References: <165490039431.944052.12458624139225785964.stgit@omen>
 <bb120b4a-e6f6-de81-35f0-9803acf9b0be@redhat.com>
 <20220615155659.GA7684@nvidia.com>
From:   David Hildenbrand <david@redhat.com>
Organization: Red Hat
Subject: Re: [PATCH] mm: Re-allow pinning of zero pfns
In-Reply-To: <20220615155659.GA7684@nvidia.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 15.06.22 17:56, Jason Gunthorpe wrote:
> 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.

^ correction, shared zeropage is never user in MAP_SHARED mappings
(fortunally).

>>
>> 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?
> 

I assume it's just some random thingy mapped into the guest physical
address space (by the bios? R/O?), that actually never ends up getting
used by a device.

So vfio simply only needs this to keep working ... but weon't actually
ever user that data.

But this is just my best guess after thinking about it.

> 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?


Good question. Maybe $something keeps retying if pinning fails, either
in the kernel (which would be bad) or in user space. At least QEMU seems
to just fail if pinning fails, but maybe it's a different user space?


-- 
Thanks,

David / dhildenb