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 <dhowe...@redhat.com> 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 <dhowe...@redhat.com> cc: Christoph Hellwig <h...@infradead.org> cc: David Hildenbrand <da...@redhat.com> cc: Lorenzo Stoakes <lstoa...@gmail.com> cc: Andrew Morton <a...@linux-foundation.org> cc: Jens Axboe <ax...@kernel.dk> cc: Al Viro <v...@zeniv.linux.org.uk> cc: Matthew Wilcox <wi...@infradead.org> cc: Jan Kara <j...@suse.cz> cc: Jeff Layton <jlay...@kernel.org> cc: Jason Gunthorpe <j...@nvidia.com> cc: Logan Gunthorpe <log...@deltatee.com> cc: Hillf Danton <hdan...@sina.com> cc: Christian Brauner <brau...@kernel.org> cc: Linus Torvalds <torva...@linux-foundation.org> cc: linux-fsde...@vger.kernel.org cc: linux-bl...@vger.kernel.org cc: linux-ker...@vger.kernel.org cc: linux...@kvack.org Reviewed-by: Lorenzo Stoakes <lstoa...@gmail.com> Reviewed-by: Christoph Hellwig <h...@lst.de> Acked-by: David Hildenbrand <da...@redhat.com> Link: https://lore.kernel.org/r/20230526214142.958751-2-dhowe...@redhat.com Signed-off-by: Jens Axboe <ax...@kernel.dk> Stable-dep-of: bddf10d26e6e ("uprobes: Reject the shared zeropage in uprobe_write_opcode()") Signed-off-by: Sasha Levin <sas...@kernel.org> 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
