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 8DC22C18E7C for ; Wed, 26 Feb 2025 14:32:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1072C280019; Wed, 26 Feb 2025 09:32:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B78728000F; Wed, 26 Feb 2025 09:32:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC120280019; Wed, 26 Feb 2025 09:32:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CF1A028000F for ; Wed, 26 Feb 2025 09:32:32 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AF282141653 for ; Wed, 26 Feb 2025 14:32:31 +0000 (UTC) X-FDA: 83162336502.17.6E2B04C Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf21.hostedemail.com (Postfix) with ESMTP id A5C3E1C0028 for ; Wed, 26 Feb 2025 14:32:29 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Z7YAxQCM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of bgeffon@google.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=bgeffon@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740580349; a=rsa-sha256; cv=none; b=UKWO4uAeCn2G/D2hPPImnVhiY9yOegBYOPvqh++KHbicFZslvAwY8dkGqvJAzGvBj7iFgS wryyzz7QG7pjDVmmxcm1q8pGOqHhma4Brc9Pi76B1Sry5xnfijTdlrV3f511XisieRum/f Cnr0gDGhXHrk8TVmLnKCALMPX7n3URM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740580349; 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=td9asxPNprcMZQkvIe996BJRz0iK1TqPUGnP0/ABMBE=; b=GzdiXqjdQu9p4D7ZzgWwxA7yxmfpx5y5984VmQNYThPFPdFNJj9HOusaGfDhDYfPZqbclO SeGKjskG6Lcrit65WdeapFSvz3HFLD8McqWPDD/u+eo2904z57DorB7m6Ves3X/+RtG86C 44Hq1nyQ0fC9cHNQG21uxnxAcQw8EOs= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Z7YAxQCM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of bgeffon@google.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=bgeffon@google.com Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-22342c56242so38295ad.0 for ; Wed, 26 Feb 2025 06:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740580348; x=1741185148; 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=td9asxPNprcMZQkvIe996BJRz0iK1TqPUGnP0/ABMBE=; b=Z7YAxQCMAyY/8aByWkg94sPronUkSYIW2DEG4lmim/cJwdQ+URCmSAe7CsOPcZPQva 3nUv8bkaA5ezyDVrqeML5rRPHXlxLqEZYeK0vA0pZ3QL5W4GdTJUXyLjXKwTuT2QWLvD MAYP5QCeVhforX3KmDauMmQxiZCQGOuaHOqV46IpVpQ6Jp8xaBWC0OiKcnAhEmHR+qPP JTuSk5qxIHdPWqAxbwIanGOUfoXXRClmBxqBzr7Na/Vi0sKcL7AD17QIisHinFMRkxW4 z9fQwZi2B4R8Lh8W5gX9jN4SNYn3/WAXMjkNP6yNcl32t4G8E+qlrmv7K1v9bIH3g+dJ pgkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740580348; x=1741185148; 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=td9asxPNprcMZQkvIe996BJRz0iK1TqPUGnP0/ABMBE=; b=Dd2ntIgOnMFUcGVy18gimC/Rpe1XP/FY3l6mVEJNRofWRzTyTp8rh2YYhdcjQ7Hlf3 6iE0wojhMEpEwPiFgMwsgKqC18j8Ocp9knCIW8Z2JlmyhNf8+/7/uwtgQ3Gm9xaCFdfV xgpsteC0xTp2gLlQkMa6xiH44K037vX3P8njEAH5/x7imJU6oDiG++bHH25Tn7wuVl3s QiMQIs/wCcLu7G9f9EWqdc8F+/3a1vMVKCwBAxW3qzNaqAQiU0/OKOEuFf6yLE/uvTwp OsDRI/vE1ppQWsQmebV8UuA03sYGgLHL3gwNTSIypkQwwt5Kul/Y8pTxx7UW9ZjySD3n ULTQ== X-Forwarded-Encrypted: i=1; AJvYcCVJ5p0+BFO82Xp3XVwTGC5ZUETQKEJdHFT62zkhZnWEveVW2ZgA/YZ55ZIblc0X70iesfLQ8srWCw==@kvack.org X-Gm-Message-State: AOJu0YzbMczilCUVM6u4IfwLzLE4r/WBungZhuhblm/Z9bvIAYanMvrP YmO7QRhvK/Gvfb3xIF2z5a0Y3h5ASyhb5fZvCmv0rM+0iyMgdux2XWMIy1KKsM0RuQpxVc7WoMs aTTgYKddNR9jrg+Zvg6nY4g9fFWivSibSR/qP X-Gm-Gg: ASbGncs1ONu/24Dr4ZGOMzTF4j35jE6jDfv+NaZbvwyV8IEn1m3CLoiAPNWFWp8hZjx vH6ZpLWFTkEr4b/Lx5FPWjtgOEW79f+yeS70LWfkQjYUVqbDAwxwU0HV+OBb88HPI19Vux/kDsw UfKu7K2A== X-Google-Smtp-Source: AGHT+IEV7oIAxW6mnHKhBlIrbZwecYCm5nSGQwXbP+kYpROVcMIbhN327FZxfj24JStSXf63AwfCMV6rWezOiQiGmYU= X-Received: by 2002:a17:902:ea0a:b0:216:21cb:2e06 with SMTP id d9443c01a7336-22307a97497mr6478505ad.19.1740580348078; Wed, 26 Feb 2025 06:32:28 -0800 (PST) MIME-Version: 1.0 References: <20250226114815.758217-1-bgeffon@google.com> In-Reply-To: From: Brian Geffon Date: Wed, 26 Feb 2025 09:31:51 -0500 X-Gm-Features: AWEUYZn6pM-y42p_MFAy4Xy3EXUzYgSyyByB_sRAby2IurtgY3iUwDA_grGzwRU Message-ID: Subject: Re: [PATCH] mm: fix finish_fault() handling for large folios To: Matthew Wilcox Cc: Andrew Morton , Zi Yan , Kefeng Wang , Suren Baghdasaryan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Baolin Wang , Hugh Dickins , Marek Maslanka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A5C3E1C0028 X-Rspamd-Server: rspam08 X-Rspam-User: X-Stat-Signature: pjr4pmemciyho4sqkenq3r6ghguzwk9e X-HE-Tag: 1740580349-155818 X-HE-Meta: U2FsdGVkX18+tHw3yZAiIpVwzy6L/+HJIndld8qHn/12BTurdpoY7mZLVPg0dsoPUWZFON8CgHRuw9hJOvsVO1oAh2wvjw4CeHMwUxcBdhBWz5We7rojRBkF1UG6F0PXVCsZy1flfgEu2WTvUM+CG0s7kM7NQUGWUWN46zQlUJB3zocXNEZG596lkpKC23/p+uMsk9Aq/17MknrQIgBr6LyBWmoKTfKddKU8foYFJF0jlVxS9Vkdo+KsWbuBr/97sjI4nJQDB3Vvrl/cBCB0eNzpYovFfYHFEZFi67MaWVTMN/qF8BttwvVwpjtbThSDuGm6SLY/d1fV4LMgrgTxBgh/vaD8wDt5sx/HVZ8qOFjtWdzu8lyxZwnGKAgJdgZp4lLOBVJd81koG6gAcLqu8gF41XgtUrG8RCWn6YkxUsBI/75bX08oX0K7zPBE2lOYq0HEJ3fe+7okkNRbGsTw0D37ktUBjxIJ303DHMkqbt6hcTw9O+Zom2CBzATs7397f9JkycSjan9nLgGauPeeOzn5nZJZv/F8gJkJqipKqQeGVR6MQF6rtJtHj1ft4LBfufriZlD6Jm/pPQScc7NCTfNXmGpucOvEV8Dot4md7TqQkDrucwvll78fSiWKQVaCmP9jVeYFsWw75R/b42eyX/JPSEc7xAElgyjR2xjQN+YThZG8OgeEIQCNEEAiiNoWBjHlu2aBehD56CXJcOwEWBpZtHGrb+6xCRopeAMXC+E/1wVJmF2Ejp0UVwoTVpGuCB4ddxuvHSeVFlE0I3NnAlttptbZBiwrkF+fCgAMCLUdt2YqnUBu0Z2YAR043HdlSYSqGUnDtSkypiyB5pXBNUR577QFKBS/CBOTJ2W06UP1B2UuNenliMs2jI1tNJ1IrG/QZKxei/SjiL+iIFxOEvBInhpm8XOfg1MIfseZzkZvnzAz9YFHkL3JKxtquFwY5+HHuap2yEiWE5bwGLn hjsZEhWP 6AsJ+54v73AVbV3HIyK5N92+m23M/VL9qbHtI24+ifxklhKHJtQcyBUmFO6w99ShDMeVKzIAnba5NM5ZT+upn70qq9g06IxGXYBjXFSxjbe3OakTETR50Qalf0FFFRDYP3ilDlts0CGwj/keX50QqO5HiPgd5tkgEtT6I7oDaEFsxoNZ0Sg7Mp1rAirQcbtgEw67ecBlrCkQNtmkAtAqPYMitt4Xb6fjc1oSEOtHAdV6S9I7iDQS3Y/wCN70EKc8ERC3kp2faAK7x6U9LvZjC8pi8f3fr4JocbaFkTXRiIbN9Hmg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.015185, 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 Wed, Feb 26, 2025 at 9:04=E2=80=AFAM Matthew Wilcox wrote: > > On Wed, Feb 26, 2025 at 06:48:15AM -0500, 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 just the pte for the > > address that triggered the fault. > > Surely there's a similar problem in do_anonymous_page()? > > At any rate, what a horrid function finish_fault() has become. > Special cases all over the place. What we should be doing is > deciding the range of PTEs to insert, bounded by the folio, the VMA > and any non-none entries. Maybe I'll get a chance to fix this up. I agree, I wasn't thrilled that the fix looked like this but I was trying to keep the change minimal to aid in backporting to stable kernels where this behavior is broken. With that being said, do you have a preference on a minimal way we can fix this before finish_fault() gets a proper cleanup?