From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F381C19F2E for ; Thu, 27 Feb 2025 16:47:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1ED96B0088; Thu, 27 Feb 2025 11:47:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CCF096B0089; Thu, 27 Feb 2025 11:47:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B97496B008A; Thu, 27 Feb 2025 11:47:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9787D6B0088 for ; Thu, 27 Feb 2025 11:47:43 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 52D61B70E6 for ; Thu, 27 Feb 2025 16:47:43 +0000 (UTC) X-FDA: 83166306006.29.C81204E Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf26.hostedemail.com (Postfix) with ESMTP id 3AD69140008 for ; Thu, 27 Feb 2025 16:47:41 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=OO3aIVvt; spf=pass (imf26.hostedemail.com: domain of bgeffon@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=bgeffon@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740674861; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cjQglI5Jx4hFLotBiZ0PYZgwKxX6om4t0kw+FgWAq7w=; b=XFwOMLCcAXmiQYYCDCq/AK8FP6mDQ5uvI5jfSf+J8vqMnXmlqxj8xS8nrHT6M7Ap9QssOb fAmikx+JUztO8tVipXdcEHvnzDbtm7TT8bqd0sieR4nMmC5kHfA66f8qyOGC9jqc5mQXDl iBquABcoR16Igq8KDxmz4Fd2eicUjFc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740674861; a=rsa-sha256; cv=none; b=kqEOcUvBsnf4xkXd3Mrw7ILUhtD1ymA8o7cU+GT/+d09QE7cEFLw4b9b/DC41SvKLhErj9 nQGW+aUiQq+e7ad6TRYOrNogkgquYAn6d2rLPJaG04KAuaC+RIcSfAIwgf+WjY+dcaW2qZ 6bwv3C6UP/0Q2/rXoa28EyoCD4a+hIc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=OO3aIVvt; spf=pass (imf26.hostedemail.com: domain of bgeffon@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=bgeffon@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-221ac1f849fso159295ad.1 for ; Thu, 27 Feb 2025 08:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740674860; x=1741279660; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cjQglI5Jx4hFLotBiZ0PYZgwKxX6om4t0kw+FgWAq7w=; b=OO3aIVvtMumz6qRJG0Bjo9DAAmv7xukAk2b+u9BvfjTtGFNHd6M421qz+eRqAqOVpr WRKsTcJ27HAxngVrqNJ2SFWEEN//JlFzGqzp6FeQ+2j7OkaQGibVkA6BZfBret3mnBoF WNastTLdNIFu0jwOppqqRrM0hEpH5fYKVS2K4RgYXruvpzyE3cShs93OeZQeePIePG4J owPDMCv/HJqtVGiTXu5WgC9t/KceEp/t0gPVGZA2VGc/W0iqhDrQAzSUmyctOTpS0G/E cKnZQxw3kAVkwWuRZNbMHeKOFc3iSBwkjpR90gRVsEC1GJg10l+VcANzCPFG7NDOC0A6 6BPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740674860; x=1741279660; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cjQglI5Jx4hFLotBiZ0PYZgwKxX6om4t0kw+FgWAq7w=; b=WB/tt19+E6AwC81bxpRj13pJvS7T1OVIvVMV1+FYbq0PNySiKomteBPr0UzIunkLR/ edrkxI+RpBa7U2I8i2Iqec8PVOoJI6LLm5lwmSIbiU4yyX/WsbNgp8fsl4A77pzkrpZ7 xfTaG8fNfN7G8tOGZiX1MXdY4ezWp52u5ADiG8dvHWSIErn1Jmyymb0oFibDYo+fIjwY BLHmj0btqzA2IKKVVPlKhlHKrGGh2Se3BzLaUA+U+zVOjar+noRLLATsADAflXb2duQ7 p39PYs/Y8BoLvjqYP73P4hbDt4d2EkziEwmY2hBiMyNw0+O+xvDCld0r2Qj9G5e/udo9 13vw== X-Forwarded-Encrypted: i=1; AJvYcCV1bHkSXP6HQcCaQtbG0+zYJKYDHuegyu3LEsfoE82DLCXzI+HIK+/jY649nbOg7jsdXiquLrq4uA==@kvack.org X-Gm-Message-State: AOJu0Yy5n/ZBhbX0g1jLhP7DQzgyGjPfgEswF4oTKOkzbv0LtB+8NY2G D9aMPotrHreH6jMZqkBeCm8vyW9zHqHbHnI9NH0h1CHpAZVC/KIzDyoXEPDVoGVFx87vzMIf82p ErJsLCHW095Mp3ThRokT0PPdjkqX4yW16GPkC X-Gm-Gg: ASbGncu04qxbXolNhkt2onqOe5S9LQNEQ5nFxa5vpAmzejOTgOra3MTxgNVLXbzik9N wMy6GFmcPYtO1vVTu4mEQmzZj5V9JlIsDFb0bYgi8WLWPuHSLIdPlcx0JD35OqHxICk5latHSVL sg8aTQxg== X-Google-Smtp-Source: AGHT+IGbh2l4ajVTrlNsPmTCm4a8bZF9mLdxtA25l6wpBcMDhLAicmrXnr5nMHmIUgLPCdLGS7Du7gykIKVTKfuq8/g= X-Received: by 2002:a17:903:2647:b0:21f:631c:7fc9 with SMTP id d9443c01a7336-2234d3abb47mr3241885ad.0.1740674859774; Thu, 27 Feb 2025 08:47:39 -0800 (PST) MIME-Version: 1.0 References: <20250226114815.758217-1-bgeffon@google.com> <20250226162341.915535-1-bgeffon@google.com> <19624e55-ba41-41e7-ba11-38b6ab3b96e5@linux.alibaba.com> In-Reply-To: <19624e55-ba41-41e7-ba11-38b6ab3b96e5@linux.alibaba.com> From: Brian Geffon Date: Thu, 27 Feb 2025 11:47:02 -0500 X-Gm-Features: AQ5f1JrSljmPZJRVpwmBaun-Y2rCm8rPURUzFaXgFgfmntTS2L4B3GhyxYNcs0U Message-ID: Subject: Re: [PATCH v2] mm: fix finish_fault() handling for large folios To: Baolin Wang Cc: Andrew Morton , Zi Yan , Kefeng Wang , Suren Baghdasaryan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Matthew Wilcox , David Hildenbrand , stable@vger.kernel.org, Hugh Dickins , Marek Maslanka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: qpynwgws7s43nn8izmyuwq8s8kupxune X-Rspamd-Queue-Id: 3AD69140008 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1740674861-584603 X-HE-Meta: U2FsdGVkX18sRKlwr7Md5p3ZEQMzBvKsqAimwr73qj3GrxvDsnQh5uWduZILeksLuRUzcZO8NDXD4HzRQBdVZKgAqGoOug5s5OVtCgny7c7XbNfTxUKQpDA2g0+q5ooizX9kPughPRliKw7wcs1+9FFPDXe5QqpCLWJEYzFyPns/TLddR9Gg+NkvC0d1RZ9U7a2G75ZX+obXNhpergXHEZ7Atle+UfwEm62m6DUpjQPgBA5ErZcVyooIfhJPkvIGRcx5A6Df4NiFtUlECIOyfAx4oVKxFJLfIMGlbRMvcz1NoE0jzS05IRLFIFx9FWzYRJrnHhvgrqeY9t3BTh4kqdJmwCiZ/jGFMaEt0WRLQYjkEFI4pmHUlDqTa1HR7NZQ+hNR/ZicsTUcbRZMXugTHdFDN2KaR4TVQXCtQ5wcQvINJR5jmz/65frH33aTZLLMa6PZSmi19cgTRVnYfKE9U3hBeG8NadYowuJWqRw4pmSGjevzYb5c0Mz+XwLovDIIgcF14TMtchJ7H/sSTrgMv94hmzSB/wkZV1pJL0zu2bWt9A03WbQMbHUMkMO93eaXol6xAR9KGab5BTAvYelgHVH8bz24Cuk5XQKQ2DnY5pRdloFLtPrP6JE0kTFVZWbLqb+H75TduUehTom+p28DKrQMfRDAvuin71Cs8FitSpotlxCGfZ1kx4fJ72wKz+aKd+HNHb6ZIih4Ky5X5PL+6fCHOJ5SvBo2JZIsAAhMZY0gJYpbumkeHcFyn4w68sMX8irn2aoQ/E9GPi6ewkcIfB48ZeBi5Mr17N3bKmiFCiNdiyVgydbud+0KLKBbd98U2zs7nxOBIfCUykpA/ic6OFKZTarZcJw4VYN0RdVMwkok0UGndOLXOn9mkFTb8v2NU+2nzH6zwPmnYyC430fTa3F3kN+gi2B/UhdLhAuFI6mur08/uQ0EnLzARbZ6/mOw6U6GdNypAbs2GWovCPy pgwxHjaj k/0T/2TZMeJDFgfBS2q7eVbarOTa8IqVDVdQmHZKmwm9u+3jgcGZ8iIBAR+kYSI8qTsfFUqzKHiH1DGJw4oaasCooY1+l2+Tfy9hYkdfqHNRDUF3ExysUVZUPRGjSZX9xsNTLZypIV5tfAmfCnDllcM4raUs/qztSpowlIOY03BuM3Wpmf5RbLk9gyUbektZAGKo1k6tqga/V8b3+1TX7Gob2ExPkzQwto+2z1uIV1PVqLX5h3AMqtvOLLohNA9lB7/3pfwqmT2S+qVnsbNh/BV4F+7sUdU251Ze2MZM7vl92s6PAN8xl3nFt8Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Feb 27, 2025 at 2:34=E2=80=AFAM Baolin Wang wrote: > > > > On 2025/2/27 00:23, Brian Geffon wrote: > > When handling faults for anon shmem finish_fault() will attempt to inst= all > > ptes for the entire folio. Unfortunately if it encounters a single > > non-pte_none entry in that range it will bail, even if the pte that > > triggered the fault is still pte_none. When this situation happens the > > fault will be retried endlessly never making forward progress. > > > > This patch fixes this behavior and if it detects that a pte in the rang= e > > is not pte_none it will fall back to setting a single pte. > > > > Cc: stable@vger.kernel.org > > Cc: Hugh Dickins > > Fixes: 43e027e41423 ("mm: memory: extend finish_fault() to support larg= e folio") > > Suggested-by: Baolin Wang > > Reported-by: Marek Maslanka > > Signed-off-by: Brian Geffon > > --- > > mm/memory.c | 15 ++++++++++----- > > 1 file changed, 10 insertions(+), 5 deletions(-) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index b4d3d4893267..b6c467fdbfa4 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -5183,7 +5183,11 @@ vm_fault_t finish_fault(struct vm_fault *vmf) > > bool is_cow =3D (vmf->flags & FAULT_FLAG_WRITE) && > > !(vma->vm_flags & VM_SHARED); > > int type, nr_pages; > > - unsigned long addr =3D vmf->address; > > + unsigned long addr; > > + bool needs_fallback =3D false; > > + > > +fallback: > > + addr =3D vmf->address; > > > > /* Did we COW the page? */ > > if (is_cow) > > @@ -5222,7 +5226,8 @@ vm_fault_t finish_fault(struct vm_fault *vmf) > > * approach also applies to non-anonymous-shmem faults to avoid > > * inflating the RSS of the process. > > */ > > - if (!vma_is_anon_shmem(vma) || unlikely(userfaultfd_armed(vma))) = { > > + if (!vma_is_anon_shmem(vma) || unlikely(userfaultfd_armed(vma)) |= | > > + unlikely(needs_fallback)) { > > Nit: can you align the code? Otherwise look good to me. I mailed a v3 with adjusted alignment, I'll let Andrew decide which variation he prefers. > > > nr_pages =3D 1; > > } else if (nr_pages > 1) { > > pgoff_t idx =3D folio_page_idx(folio, page); > > @@ -5258,9 +5263,9 @@ vm_fault_t finish_fault(struct vm_fault *vmf) > > ret =3D VM_FAULT_NOPAGE; > > goto unlock; > > } else if (nr_pages > 1 && !pte_range_none(vmf->pte, nr_pages)) { > > - update_mmu_tlb_range(vma, addr, vmf->pte, nr_pages); > > - ret =3D VM_FAULT_NOPAGE; > > - goto unlock; > > + needs_fallback =3D true; > > + pte_unmap_unlock(vmf->pte, vmf->ptl); > > + goto fallback; > > } > > > > folio_ref_add(folio, nr_pages - 1); Thanks for looking Brian