From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BFE49235348; Tue, 15 Apr 2025 18:59:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744743565; cv=none; b=SNJ1zk6sxPMf3RQiqn1wUOiKvKOeNYt8zg6qTmwDkWmdZT8UO3KnZ9Vnl9fzeWZe0+YmnHDHQFtUBIcNbWIr7+OL+z3SzCRjKCYa6OIaqB+NwfHkz5W6xtDh+4g5rPDoGWmnFNSyRZu0DF98DtSf1ZURqQThBtJojDpzDKR+CeU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744743565; c=relaxed/simple; bh=q70ctjrGqLmxVUHKXN5p9/vzscrDP14u951WDIoOWbg=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=WhhobfJEibefFaQ0JTsYuK5380cDANeUzvLEvgyk5jsUlc1zCR/I/SKM/Y+dyjyLB6YZRodeW1bilg+tiivkZbtOaPQm3iYPXbyCP1VRGSdSPK5atfsGA4OMsiVnpvbcdEz/WfYVyRsWoGvXO5pQPaKZT/H/2CTssFADmCtG6BM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AAm6SqV9; arc=none smtp.client-ip=209.85.218.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AAm6SqV9" Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-acae7e7587dso521883066b.2; Tue, 15 Apr 2025 11:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744743561; x=1745348361; darn=vger.kernel.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to; bh=hkp2i5c9bgqxiRKG/3h+HqHChQz8elSJkULnjDgaezo=; b=AAm6SqV9K46+AYF9omCKS9PgDmqtxglc1hVXx8UUxDbiFBaXbl3iDSQShCztoLcSI4 M7J5n9hR1fJ/rPWCj/KvviUT/1PMbnCixa80scuMaZhM+GnE71Uk2RcVZr+Fvax0X6WN b2KSUIGqX7snDdwzAPrPBcheS7hIWSgLWXj+OMaWLgFhbiEgPIbMSti0VWwP6EsYbje3 rbHP3jKKKHPQiInU7kBmQwL1XWlHjqnKvvg61vt+4WKZqVAl/6oNejx2UtE8tCzuK1bO zePBA42lwRO6KcLy7e2r0EcspYGdCGeO6SrAC4dRRsc7FJRKLqsZGWE9+jLLPIWNbJu1 c9EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744743561; x=1745348361; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hkp2i5c9bgqxiRKG/3h+HqHChQz8elSJkULnjDgaezo=; b=Le1YOfLR59qAh7TOjKtSt71IKB3IDOJOA5g41RstcbuDUlwwuBFMS5sHfncP/xkS6M bH9mSP45NAERSQL0fLFCGHb085zdqJwXH8vCVqqjSf6Xk4HO/Q+oTopdCju7IYOhMNQn g7SuhGIWjtwC3Glf0DRFeq9Q5TrQD5nnCEQfhRASzqDRBhze4ANnjkgr9REeSH6/aqlq 7jNpY+hHD963OX4bzln9Joe7hXPmlikIbHtIdYrPvTX89qhTi+xIgnJcAhnGnQVK86Nx gv2AAU1LmBDJr7uQUqxstADJNZcKGfx4CecpMGFtd5h1XkGvbWzvngJ2FO7uVR0U5m96 tdag== X-Forwarded-Encrypted: i=1; AJvYcCU3tZxmtVDSld8moPSEhC57PN1vval355yqATP1xOwVPva6HXZL7/RGErw+meIdD3V+vKskuuA=@vger.kernel.org, AJvYcCWpx9lyvaMH2zIB/M159z/8uTY2yTAmc7SkJboSOaa4Xcv9GRMzmJo9JzTQw6RnnTgoo75uGgiKPTenIsAG@vger.kernel.org, AJvYcCX1/GJT5FsbI4UuKzuw9yAiG/OHsY755LOXwVntNr6CD7x2bMZl6LHd1RjPab35821eTrPhgV/IoNJxVw==@vger.kernel.org X-Gm-Message-State: AOJu0YxBX5CbkMewnX7Tgu+dS3ANpZEJf5qp/6lgERygck3g/oen7Rp3 JQhR5nE0jp7rhu//cyDqngXO5t9zj7aWO9KkAoCPWjg5ktEaYeRD X-Gm-Gg: ASbGncuUd2pX5did0/eV/Uv50qaqKgjf3Zc94lcColtw71CyGudTPcxbxIsHgjiNpxM EEdmllkq5echuQQXvE0J96mkhaSNMVPFAAi3/XuZsvKc9tT6IPVsf++NpZelNBfKoqg0JvjzNp3 CyQxroxOYwLxlANwZYWRREuYbEtCaxisOktLN0hoxfJLqxOZlIiRzGl3AxpshwH549roNl+tSbF Naq2nGHRCsxzO6h+iYyWK63UW/p1NAE4k5PYGY+5yYtKxV9krgTfn/S0Lar5v41H59JhukC4jrp 7JfJomn7Gxs3qkAXYASgdCMWnXGY1Lr4dC/BK/BsNoAc/037Jn+7y1veB9czSPPkJv04O51oIQ= = X-Google-Smtp-Source: AGHT+IGTCiRplDt7X2b9oOiIqzPnVtzAVrCP2VkK30vBE7aX2MZ8ZaJbKZHqziYeL/Ig1EMQ0/BoBQ== X-Received: by 2002:a17:907:720a:b0:abf:6cc9:7ef5 with SMTP id a640c23a62f3a-acb3850f00dmr12406966b.47.1744743560630; Tue, 15 Apr 2025 11:59:20 -0700 (PDT) Received: from eldamar.lan (c-82-192-244-13.customer.ggaweb.ch. [82.192.244.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-acb20c03de9sm177102666b.71.2025.04.15.11.59.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Apr 2025 11:59:19 -0700 (PDT) Sender: Salvatore Bonaccorso Received: by eldamar.lan (Postfix, from userid 1000) id 25073BE2DE0; Tue, 15 Apr 2025 20:59:19 +0200 (CEST) Date: Tue, 15 Apr 2025 20:59:19 +0200 From: Salvatore Bonaccorso To: David Howells , Christoph Hellwig , David Hildenbrand , Lorenzo Stoakes , Andrew Morton , Jens Axboe , Al Viro , Matthew Wilcox , Jan Kara , Jeff Layton , Jason Gunthorpe , Logan Gunthorpe , Hillf Danton , Christian Brauner , Linus Torvalds , Sasha Levin , Greg Kroah-Hartman Cc: linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, regressions@lists.linux.dev, table@vger.kernel.org, Bernd Rinn , Karri =?iso-8859-1?Q?H=E4m=E4l=E4inen?= , Milan Broz , Cameron Davidson , Markus Subject: [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 Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 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 cc: Christoph Hellwig cc: David Hildenbrand cc: Lorenzo Stoakes cc: Andrew Morton cc: Jens Axboe cc: Al Viro cc: Matthew Wilcox cc: Jan Kara cc: Jeff Layton cc: Jason Gunthorpe cc: Logan Gunthorpe cc: Hillf Danton cc: Christian Brauner cc: Linus Torvalds cc: linux-fsdevel@vger.kernel.org cc: linux-block@vger.kernel.org cc: linux-kernel@vger.kernel.org cc: linux-mm@kvack.org Reviewed-by: Lorenzo Stoakes Reviewed-by: Christoph Hellwig Acked-by: David Hildenbrand Link: https://lore.kernel.org/r/20230526214142.958751-2-dhowells@redhat.com Signed-off-by: Jens Axboe Stable-dep-of: bddf10d26e6e ("uprobes: Reject the shared zeropage in uprobe_write_opcode()") Signed-off-by: Sasha Levin 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