Messages in this thread | | | Date | Wed, 15 Jun 2022 12:56:59 -0300 | From | Jason Gunthorpe <> | Subject | Re: [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
| |