[regression 6.1.y] Regression from 476c1dfefab8 ("mm: Don't pin ZERO_PAGE in pin_user_pages()") with pci-passthrough for both KVM VMs and booting in xen DomU

[Salvatore Bonaccorso]

Hi

[Apologies if this has been reported already but I have not found an
already filled corresponding report]

After updating from the 6.1.129 based version to 6.1.133, various
users have reported that their VMs do not boot anymore up (both KVM
and under Xen) if pci-passthrough is involved. The reports are at:

https://bugs.debian.org/1102889
https://bugs.debian.org/1102914
https://bugs.debian.org/1103153

Milan Broz bisected the issues and found that the commit introducing
the problems can be tracked down to backport of c8070b787519 ("mm:
Don't pin ZERO_PAGE in pin_user_pages()") from 6.5-rc1 which got
backported as 476c1dfefab8 ("mm: Don't pin ZERO_PAGE in
pin_user_pages()") in 6.1.130. See https://bugs.debian.org/1102914#60

#regzbot introduced: 476c1dfefab8b98ae9c3e3ad283c2ac10d30c774

476c1dfefab8b98ae9c3e3ad283c2ac10d30c774 is the first bad commit
commit 476c1dfefab8b98ae9c3e3ad283c2ac10d30c774
Author: David Howells <dhowells@xxxxxxxxxx>
Date:   Fri May 26 22:41:40 2023 +0100

    mm: Don't pin ZERO_PAGE in pin_user_pages()

    [ Upstream commit c8070b78751955e59b42457b974bea4a4fe00187 ]

    Make pin_user_pages*() leave a ZERO_PAGE unpinned if it extracts a pointer
    to it from the page tables and make unpin_user_page*() correspondingly
    ignore a ZERO_PAGE when unpinning.  We don't want to risk overrunning a
    zero page's refcount as we're only allowed ~2 million pins on it -
    something that userspace can conceivably trigger.

    Add a pair of functions to test whether a page or a folio is a ZERO_PAGE.

    Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
    cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    cc: David Hildenbrand <david@xxxxxxxxxx>
    cc: Lorenzo Stoakes <lstoakes@xxxxxxxxx>
    cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
    cc: Jens Axboe <axboe@xxxxxxxxx>
    cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
    cc: Matthew Wilcox <willy@xxxxxxxxxxxxx>
    cc: Jan Kara <jack@xxxxxxx>
    cc: Jeff Layton <jlayton@xxxxxxxxxx>
    cc: Jason Gunthorpe <jgg@xxxxxxxxxx>
    cc: Logan Gunthorpe <logang@xxxxxxxxxxxx>
    cc: Hillf Danton <hdanton@xxxxxxxx>
    cc: Christian Brauner <brauner@xxxxxxxxxx>
    cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
    cc: linux-fsdevel@xxxxxxxxxxxxxxx
    cc: linux-block@xxxxxxxxxxxxxxx
    cc: linux-kernel@xxxxxxxxxxxxxxx
    cc: linux-mm@xxxxxxxxx
    Reviewed-by: Lorenzo Stoakes <lstoakes@xxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Acked-by: David Hildenbrand <david@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20230526214142.958751-2-dhowells@xxxxxxxxxx
    Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
    Stable-dep-of: bddf10d26e6e ("uprobes: Reject the shared zeropage in uprobe_write_opcode()")
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

 Documentation/core-api/pin_user_pages.rst |  6 ++++++
 include/linux/mm.h                        | 26 ++++++++++++++++++++++++--
 mm/gup.c                                  | 31 ++++++++++++++++++++++++++++++-
 3 files changed, 60 insertions(+), 3 deletions(-)

Milan verified that the issue persists in 6.1.134 so far and the patch
itself cannot be just reverted.

The failures all have a similar pattern, when pci-passthrough is used
for a pci devide, for instance under qemu the bootup will fail with:

qemu-system-x86_64: -device {"driver":"vfio-pci","host":"0000:03:00.0","id":"hostdev0","bus":"pci.3","addr":"0x0"}: VFIO_MAP_DMA failed: Cannot allocate memory
qemu-system-x86_64: -device {"driver":"vfio-pci","host":"0000:03:00.0","id":"hostdev0","bus":"pci.3","addr":"0x0"}: vfio 0000:03:00.0: failed to setup container

(in the case as reported by Milan).

Any ideas here?

Regards,
Salvatore