linux-kernel - Re: [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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z_6uhLQjJ7SSzI13@eldamar.lan>
Date: Tue, 15 Apr 2025 21:07:48 +0200
From: Salvatore Bonaccorso <carnil@...ian.org>
To: David Howells <dhowells@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	David Hildenbrand <david@...hat.com>,
	Lorenzo Stoakes <lstoakes@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jens Axboe <axboe@...nel.dk>, Al Viro <viro@...iv.linux.org.uk>,
	Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>,
	Jeff Layton <jlayton@...nel.org>, Jason Gunthorpe <jgg@...dia.com>,
	Logan Gunthorpe <logang@...tatee.com>,
	Hillf Danton <hdanton@...a.com>,
	Christian Brauner <brauner@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Sasha Levin <sashal@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-fsdevel@...r.kernel.org, linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	regressions@...ts.linux.dev, stable@...r.kernel.org,
	Bernd Rinn <bb@...n.ch>,
	Karri Hämäläinen <kh.bugreport@...look.com>,
	Milan Broz <gmazyland@...il.com>,
	Cameron Davidson <bugs@...idsoncj.id.au>, Markus <markus@...tz.box>
Subject: Re: [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

[resent with correct stable@...r.kernel.org list]

On Tue, Apr 15, 2025 at 08:59:19PM +0200, Salvatore Bonaccorso wrote:
> 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@...hat.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 <dhowells@...hat.com>
>     cc: Christoph Hellwig <hch@...radead.org>
>     cc: David Hildenbrand <david@...hat.com>
>     cc: Lorenzo Stoakes <lstoakes@...il.com>
>     cc: Andrew Morton <akpm@...ux-foundation.org>
>     cc: Jens Axboe <axboe@...nel.dk>
>     cc: Al Viro <viro@...iv.linux.org.uk>
>     cc: Matthew Wilcox <willy@...radead.org>
>     cc: Jan Kara <jack@...e.cz>
>     cc: Jeff Layton <jlayton@...nel.org>
>     cc: Jason Gunthorpe <jgg@...dia.com>
>     cc: Logan Gunthorpe <logang@...tatee.com>
>     cc: Hillf Danton <hdanton@...a.com>
>     cc: Christian Brauner <brauner@...nel.org>
>     cc: Linus Torvalds <torvalds@...ux-foundation.org>
>     cc: linux-fsdevel@...r.kernel.org
>     cc: linux-block@...r.kernel.org
>     cc: linux-kernel@...r.kernel.org
>     cc: linux-mm@...ck.org
>     Reviewed-by: Lorenzo Stoakes <lstoakes@...il.com>
>     Reviewed-by: Christoph Hellwig <hch@....de>
>     Acked-by: David Hildenbrand <david@...hat.com>
>     Link: https://lore.kernel.org/r/20230526214142.958751-2-dhowells@redhat.com
>     Signed-off-by: Jens Axboe <axboe@...nel.dk>
>     Stable-dep-of: bddf10d26e6e ("uprobes: Reject the shared zeropage in uprobe_write_opcode()")
>     Signed-off-by: Sasha Levin <sashal@...nel.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