From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D25BA3DCD9D for ; Thu, 9 Jul 2026 12:17:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783599428; cv=none; b=Wao7UGnH9rXaa7Xoz9LpQWB0v3l4DpNDfV/2QU6BOV66PEcW1Upxyh8qdNUjCOb7YHvfJKUkOvrIGfns1TA1OKWtgJ0I526f4lWt0DCxfdw/syEeDxTkJIIcJHFy+eA9GrzMzv1R2nWokldKT615qsqRmN4rKrMEViB1POAMy+Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783599428; c=relaxed/simple; bh=fLJdtvh+XSoFGSp9Q5uKyghD0EL7bK3axeyouwSfots=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qMBqzCxeRq2VjQbM5XN+fd9YS/O74YfDFrlJuuaNETZ73d1jDXMHUItGoxxxQ+IwtXvR3YaoHHEF4A8rpEbqFjfj5etf4UzvopcXsM0Gs3ayIBQJPfHrg0uPuNv4STdgSs+CLalBd/KlhblFB49o+VIeaImMIC3yaYRrmeASKKU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=jMU2o2Tk; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="jMU2o2Tk" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D2ACF339; Thu, 9 Jul 2026 05:17:01 -0700 (PDT) Received: from [10.164.19.51] (unknown [10.164.19.51]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4A8143F66F; Thu, 9 Jul 2026 05:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783599426; bh=fLJdtvh+XSoFGSp9Q5uKyghD0EL7bK3axeyouwSfots=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=jMU2o2Tk7QjHBCX7BIc0yhcZRB9HdkcINy+//dBmeDvcqYIDBGUJsg3Uw/6krqaF6 j7vaKkcekKKmzWCKIIXjj9A5/yNYJr17MI6ynWYPdC+elAAIFsXa4la6LVZA783olX 9mZyKQbpt6kqwaVx5U1iOp6eAMZx8/JyDtEGstfc= Message-ID: <61fb2165-bc58-4c54-84b2-4ada10b19bcf@arm.com> Date: Thu, 9 Jul 2026 17:46:59 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/5] mm/rmap: refactor some code around lazyfree folio unmapping To: "David Hildenbrand (Arm)" , akpm@linux-foundation.org, ljs@kernel.org, muchun.song@linux.dev, osalvador@suse.de Cc: riel@surriel.com, liam@infradead.org, vbabka@kernel.org, harry@kernel.org, jannh@google.com, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ryan.roberts@arm.com, anshuman.khandual@arm.com References: <20260707121128.373192-1-dev.jain@arm.com> <20260707121128.373192-4-dev.jain@arm.com> <22fb2f54-da23-40b2-91f5-aeaf54037bcd@kernel.org> Content-Language: en-US From: Dev Jain In-Reply-To: <22fb2f54-da23-40b2-91f5-aeaf54037bcd@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07/07/26 7:48 pm, David Hildenbrand (Arm) wrote: > On 7/7/26 14:11, Dev Jain wrote: >> For lazyfree folio unmapping, after clearing the ptes we must abort the >> operation if the folio got dirtied or it has unexpected references. >> >> Refactor this logic into a function which will return whether we need >> to abort or not. >> >> If we abort, we restore the ptes and bail out of try_to_unmap_one. >> Otherwise adjust the rss stats of the mm and jump to a label. >> >> Also rename that label from "discard" to "finish_unmap"; the former >> is appropriate in the lazyfree context, but the code following the label >> is executed for other successful unmap code paths too, so 'discard' does >> not sound correct for them. >> >> No functional change intended. >> >> Signed-off-by: Dev Jain >> --- >> mm/rmap.c | 87 +++++++++++++++++++++++++++++++------------------------ >> 1 file changed, 49 insertions(+), 38 deletions(-) >> >> diff --git a/mm/rmap.c b/mm/rmap.c >> index 934773dfa2f2a..00b571c2a1bab 100644 >> --- a/mm/rmap.c >> +++ b/mm/rmap.c >> @@ -2067,6 +2067,52 @@ static bool try_to_unmap_hugetlb_one(struct folio *folio, >> return ret; >> } >> >> +static inline bool ttu_anon_lazyfree_folio(struct vm_area_struct *vma, >> + struct folio *folio) >> +{ >> + int ref_count, map_count; >> + >> + /* >> + * Synchronize with gup_pte_range(): >> + * - clear PTE; barrier; read refcount >> + * - inc refcount; barrier; read PTE >> + */ >> + smp_mb(); >> + >> + ref_count = folio_ref_count(folio); >> + map_count = folio_mapcount(folio); >> + >> + /* >> + * Order reads for page refcount and dirty flag >> + * (see comments in __remove_mapping()). >> + */ >> + smp_rmb(); >> + >> + if (folio_test_dirty(folio) && !(vma->vm_flags & VM_DROPPABLE)) { >> + /* >> + * redirtied either using the page table or a previously >> + * obtained GUP reference. >> + */ >> + folio_set_swapbacked(folio); >> + return false; >> + } >> + >> + if (ref_count != 1 + map_count) { >> + /* >> + * Additional reference. Could be a GUP reference or any >> + * speculative reference. GUP users must mark the folio >> + * dirty if there was a modification. This folio cannot be >> + * reclaimed right now either way, so act just like nothing >> + * happened. >> + * We'll come back here later and detect if the folio was >> + * dirtied when the additional reference is gone. >> + */ >> + return false; >> + } >> + >> + return true; > > You could simply do > > > /* > * Additional references could be due to GUP or from a speculative > * lookup. ... Are you also suggesting to shorten the comment? > */ > return ref_count == 1 + map_count; Yes much better. > > > Nothing else jumped at me > > Acked-by: David Hildenbrand (Arm) >