From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (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 B3ECB32FA3D for ; Tue, 3 Mar 2026 12:50:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772542215; cv=none; b=i/oQ4XeSyErAA5UWrRio+jhxKX+AqJo7WHp9TT1QX+PZLjY75SbOB57ohEDUA3l3gLsuAX5nkorBXPPgjdSGylBM3fF28unfSxq6zgMlLFIfpFmOIKDRHCoVvbbSCFtxbPLzjX1FWX9cgmF9kDMcnuekKVpJWNNUNrVUq6epaT8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772542215; c=relaxed/simple; bh=ASSYqnNargjPkzr2H4GwHjs9spO4sQXN7yuig5YSAv4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Vi9RsNqhCMfP6Ru0waH79xNgYjFtT26I6XclA/bV8Lwy4uE9UmI/gKxQDSpImM/fwDTHNXW4neRGpXQ/GYk8CHMzXLB0lxwxQ/r5k/V/s9lgZqKe2d5drPGmouLWXGdW8CEVak46qfa7UgLOJ8vEcC6o3jSL+iBnEQ0qPe7oXkU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lSKJwjYB; arc=none smtp.client-ip=209.85.218.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com 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="lSKJwjYB" Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-b932fe2e1a7so770295166b.1 for ; Tue, 03 Mar 2026 04:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772542212; x=1773147012; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=eQR3yhh4HdUVDg2I8t6pZIuvCqPm8OVYSM3fHUXSeCQ=; b=lSKJwjYB5fqLCiYq3n7wE4nYcNWQaTRtMcbk+uySFGRcV/TB2DwR5BG8BNTiYlSEpO J+i6sjCGGqjWnM9n300q0G5JtA/dm3m6NJCJ2U2+ELxEKmBsY74qmnwZrEZeoXlzab8O cSNh4vC1fOlicetRgK958Z7blLByC7cQcJBce9qbFAZ4MGIA8cDBom2UAMaI0g4DxLxp LS5vDi5bmQgRuyRrq+vbzmQBQFV/vq91a61ZDIFv2dcf+iVPrwsH/W5kn+GuORM6W37A XNBoj7Mko2pKNf5NxQxafTwt7jaF4r8Dk+T4JTNfLSDJG3gHupK7zoCe/ump3+bdASr6 Pl5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772542212; x=1773147012; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eQR3yhh4HdUVDg2I8t6pZIuvCqPm8OVYSM3fHUXSeCQ=; b=H/mm++gPhmWbj7GwH0jPA5cttnGvs9Qmp7mKk4aLvWP9FMZDZF5Rzu+fyDUzmdj0Y1 wXHSsmvfstPbYOI/MjbmZOy1ffg2mssEdBM5v8ATXFYNVx/df9mUBwItF6cDK2TA0Lov hr/u4/kSKkbGW2BuQtXlkZ2ffUBrDT4g2NNfHbI8lXfS8NoYw1nEHVE9vabeL2c424ck 6gjQDYwNe5OXuW8aBicXSQBwoCZ/78iCr7VLJDCgIowfDVsllqkIbbWS9P2pQk4xC5Mu EF9ISYa2XOhOryNq4ZjpOhotBG2kgl5wEFqTkh/URbylr4b8ahFnm5DlrxN/6VnkVeFe bEjA== X-Forwarded-Encrypted: i=1; AJvYcCVG+lldFtNzy0cyQ3XPQot0hgIVAe/BZPQnSibWmpqYEvNvt67OjYwprtyckoS+0NKycNcLoTfrHI6//wI=@vger.kernel.org X-Gm-Message-State: AOJu0YyXC9J0WcTQVjB042Shm7UAYX5YT+UqL7Ztcxgw6dM6OQYJsYJ+ T3AIydq6r/o9+Q+wTcbuG2wYZdBtmS6mfy1Iugch913Lr1JGDTCS2oI/ X-Gm-Gg: ATEYQzzK0zWrd5Uh2QA+hnI7NoSyizACrjmkR+6XtzkHygWhKcZHBL4A/e5iWQK8tvj t5kRpyjP60yq0+lOc/RpO3mALJVFpahAshZxsz3DkbJn92/pMu8ocHKV8SoEIslAYVcFpamLLyy BvZlU4ts+YUsH/Mixrbhl/ozeLl+6C3/Ccjo+dee5sQszTBN/OkzWXzPDzhvXnTZwtRqg2PYEY3 /J47TVnxDh+Gm/d3ApLqZteerVhs0vHfqNleHzK2B9E1/9tHh1yoS6pSgrgUxYYm+L8c+qkf0qT gBGwWLCnJnU/HnqUsL4/MwfWcbybKaaLf5p0BpML1wsLTRxhAge9pYbxHjOOvts3iPwV08dv1ZY A75jPCkA4HbFyvCKCzrjeunpiK2aw1qI8m72ce1GcHeSpjsGWZgXlWceuq9ox0WfVGF3OdwW70l mNj/I7H+b8Rmb05H8H2lR+1Q== X-Received: by 2002:a17:907:3d0d:b0:b8f:d13:def3 with SMTP id a640c23a62f3a-b93763a65bamr955636166b.19.1772542211770; Tue, 03 Mar 2026 04:50:11 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b935ab13558sm602304866b.5.2026.03.03.04.50.11 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 03 Mar 2026 04:50:11 -0800 (PST) Date: Tue, 3 Mar 2026 12:50:10 +0000 From: Wei Yang To: Dev Jain Cc: Wei Yang , akpm@linux-foundation.org, david@kernel.org, lorenzo.stoakes@oracle.com, riel@surriel.com, Liam.Howlett@oracle.com, vbabka@kernel.org, harry.yoo@oracle.com, jannh@google.com, baohua@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ryan.roberts@arm.com, anshuman.khandual@arm.com, stable Subject: Re: [PATCH v3] mm/rmap: fix incorrect pte restoration for lazyfree folios Message-ID: <20260303125010.54j3bmu3joixezkk@master> Reply-To: Wei Yang References: <20260303061528.2429162-1-dev.jain@arm.com> <20260303121727.ss3d3gbzituygb6p@master> <257aa379-64cf-47af-b48d-8817f7bca257@arm.com> 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 In-Reply-To: <257aa379-64cf-47af-b48d-8817f7bca257@arm.com> User-Agent: NeoMutt/20170113 (1.7.2) On Tue, Mar 03, 2026 at 05:55:58PM +0530, Dev Jain wrote: [...] >>> >>> Fixes: 354dffd29575 ("mm: support batched unmap for lazyfree large folios during reclamation") >>> Cc: stable >>> Signed-off-by: Dev Jain >>> --- >>> Patch applies on mm-unstable (9af4957ef127). >>> >>> v2->v3: >>> - Don't special case for anon folios >>> >>> v1->v2: >>> - Just respect the writable bit instead of hacking in a pte_wrprotect() in >>> failure path >>> - Also handle soft-dirty bit >>> >>> mm/rmap.c | 9 ++++++++- >>> 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> diff --git a/mm/rmap.c b/mm/rmap.c >>> index bff8f222004e4..5a3e408e3f179 100644 >>> --- a/mm/rmap.c >>> +++ b/mm/rmap.c >>> @@ -1955,7 +1955,14 @@ static inline unsigned int folio_unmap_pte_batch(struct folio *folio, >>> if (userfaultfd_wp(vma)) >>> return 1; >>> >>> - return folio_pte_batch(folio, pvmw->pte, pte, max_nr); >>> + /* >>> + * If unmap fails, we need to restore the ptes. To avoid accidentally >>> + * upgrading write permissions for ptes that were not originally >>> + * writable, and to avoid losing the soft-dirty bit, use the >>> + * appropriate FPB flags. >>> + */ >>> + return folio_pte_batch_flags(folio, vma, pvmw->pte, &pte, max_nr, >>> + FPB_RESPECT_WRITE | FPB_RESPECT_SOFT_DIRTY); >>> } >>> >> >> Hi, Dev >> >> When reading the code, I got one confusion. Current call flow is like below: >> >> try_to_unmap_one(); >> nr_pages = folio_unmap_pte_batch(folio, &pvmw, flags, pteval); >> .. >> pteval = get_and_clear_ptes(mm, address, pvmw.pte, nr_pages); >> .. >> set_ptes(mm, address, pvmw.pte, pteval, nr_pages); >> >> We get pteval by folio_unmap_pte_batch() but it is set again by > >folio_unmap_pte_batch() gives the batch size, not pteval. pteval is >given by get_and_clear_ptes() after accumulating a/d bits. > >> get_and_clear_ptes(), which maybe a different value. Then we use this pteval >> to restore ptes. >> >> So even we fix folio_unmap_pte_batch(), how this impact on the final restored >> value? > >By respecting writable bit, we ensure that the ptes in the batch do not >have a mix of writable and non writable ptes. > Thanks for your explanation. I got it. Then the fix LGTM. Reviewed-by: Wei Yang >So, if pteval returned by get_and_clear_ptes() is writable, then it is >guaranteed via folio_unmap_pte_batch() that the all pte values of >these nr_pages consecutive ptes, are writable. And vice versa. > >> >> Hope I don't miss something. >> >>> /* >>> -- >>> 2.34.1 >>> >> -- Wei Yang Help you, Help me