From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-a2-smtp.messagingengine.com (flow-a2-smtp.messagingengine.com [103.168.172.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CF6BC48381E for ; Thu, 27 Aug 2026 17:02:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.137 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787850178; cv=none; b=lqp9+KIL29Gu3YlVZaK/2rzz6TbX65TAoQtXkef1rfx7xpLF92gXPjbYQHAFTqoxzq7Hlcc4hkk7T/K4WPIXD12w+PZP8quc7PCl/Qy+un/zOys2ry/UVEVVQwP3YQwMML312+Dl/Yi+XyKs4BTRfQqidkkN1O/7cEDFuy4eb7A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787850178; c=relaxed/simple; bh=KGw+yWrgbH+y/nhYqiWKZ716ksUywh24nMxJ4f9sM+s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=asQdbJcQKefr83W63UGsXDA44g4mInVFlvigBJiPng69Jp2AqPQROAz6W50mpK2WTYgbMcdo2RCVoni+NhKIQs2ep4MEhIhZ1nqirJX1GvZwUuX+znAlY9XJP1J5uH10NMLZOQYfmfMjVOhj/DAUdLPC8S9mkNHEK7fyZBKuu/k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name; spf=pass smtp.mailfrom=shutemov.name; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b=myX0/GQ7; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=HI4WaUrO; arc=none smtp.client-ip=103.168.172.137 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shutemov.name Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b="myX0/GQ7"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="HI4WaUrO" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailflow.phl.internal (Postfix) with ESMTP id 2F82213801EF; Thu, 27 Aug 2026 13:02:50 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Thu, 27 Aug 2026 13:02:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1787850170; x= 1787857370; bh=RaaPIMZeB2T5hMnyz0u2F3PP1cDWDmpQMQWXSASC5eg=; b=m yX0/GQ7HePz4bzgG1Gv/dTcg1UZluSBAEih0A7hqHRFHkg5QtEkzG2tl8je8/FXw QsB+yNs8zhGdjriusj9bcEyuyeTdTSDSKjYV77gLnyFRGgPwNK69liJbKauw73FD J1iEfT4dCc3TiE+GiNr8JAPsiLZm4cj2jngHVJyMtkHhZMqEaKTWg4y6hEscnk/r RsZwSVbIoaRVsOjdg3QFmFCrUUMaUJP84VEWmEeST+7xybrRNXfq2gn3SmxRpjaC zWptz1HON9y/Hz+58o4KA5YgvEnoNiaq55IuPVhyfb+f02TIkH8RngKiSsqJz6Iu 2vsmuzq8Lcf1fG5iB94LA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1787850170; x=1787857370; bh=RaaPIMZeB2T5hMnyz0u2F3PP1cDWDmpQMQW XSASC5eg=; b=HI4WaUrO64DRYwSFlxQTpqIT6MODUIaZ7sMXOCsov+CBVwKdMYG VsZy6TsWYqPJkZGBX2s2BopyjMYVZ9iUowWlqwPC8CKs1fbcOh7p4H1jyZ72lqez szMSDhzhMiHe1LydmmURZSCeYmxBxpm9ZigMnGZZOWx18PUmlNyxzad5TKdGGL4S 6XH9KQoINmojZF1ZwPqzIgvt2+qLcDMhVSoU4Th6Cb6dTCR5tgVnc+Xrz/tRjxYp FydYOkWdFUxtAA4xTBhojDzKObm5KFGNRNG7HFD/X+bNi74zJaLtcm9eh+ZG9SFc URq6c3Z7UrDBVDoramjUoxmj4nmW/SQ7n/A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTECvBFj4noXVxqIV/w9QY/YYN1+QqbknFxJP2iS0y3HzG7Mww8Bm4WPeuj3M5Px7E Vqlrc1OhMWq5ZBjwJxKvDS8Y7/oI5oZG9au3O4wsObaXhZHPYwb8lGOkb10tik0IIdFaiQ H8SU/Nplx8LgxPgiu6JVIpaiupqTt6OrIEzIIfYyQAvCTPl0g0s8t+QhGMNke8thlvDeBx pjo0BAArBZ+Orwex3MvK+qcneAm9b33PEvGXpdKFn8mJME/MplRa1AwN6m3/6IoOabO+f1 2gUOqggbb0K6Kt9b5OEh0G0uK8TObvk/iFKHlBMT5iQfP7wL/F53E23ugA1kwb149nd7PW XbLtfwjVRvyB6S1HdwNVzSa5GyijZnxx+7KKqA82FRescFco1aUcRSCPavSSg/PnuZHuSD WGWt+rU1bBC5PaAN0MzBgXaxbP9yel3wA0xMA52Fm9LnL1MaW8MQe/kiSNO5g9bJAsI785 AVn6dopBnGpPU31m80J6vChLqLlx1DXEUkAQs/jUBjPIEUKs8LlI/UXXAZS0Ssrezw2LSd BYL8Ey9/DkvAInufBO7EJPsmbxRvuU5pjJ/zQXUMi1j/2396RGsXjsoyPxGPcdMHweMswz ckiul6qKidG76c7f4aFX7+Wx9MJunEBzceMbn7cnctUGfiqP21dgUfPfZwlw X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Aug 2026 13:02:46 -0400 (EDT) Date: Thu, 27 Aug 2026 18:02:45 +0100 From: Kiryl Shutsemau To: "David Hildenbrand (Arm)" Cc: kasong@tencent.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Lorenzo Stoakes , Zi Yan , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Lance Yang , Usama Arif , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Chris Li , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Shivam Kalra , Kairui Song Subject: Re: [PATCH v3 02/18] mm/huge_memory: fix rejection of swap cache folios with a mapping Message-ID: References: <20260821-swap-thp-cleanup-v3-0-9b43f5163238@tencent.com> <20260821-swap-thp-cleanup-v3-2-9b43f5163238@tencent.com> <50bb70bc-d442-43df-ab4f-a158c8b05ac7@kernel.org> 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: <50bb70bc-d442-43df-ab4f-a158c8b05ac7@kernel.org> On Thu, Aug 27, 2026 at 06:00:33PM +0200, David Hildenbrand (Arm) wrote: > On 8/20/26 20:55, Kairui Song via B4 Relay wrote: > > From: Kairui Song > > > > A folio in the swap cache cannot be split if it has a mapping (shmem). > > The split code does a defensive check for this in > > __folio_freeze_and_split_unmapped, after the folio ref has been frozen > > and the NR_SHMEM_THPS/NR_FILE_THPS counters have been decremented. It > > rejects the split and returns -EINVAL without unfreezing the folio or > > restoring the counters. That error path is buggy: if it is ever taken, > > it leaves the folio frozen and stuck, skews the counters, and fires > > the VM_WARN_ON_ONCE_FOLIO for a state that is actually legitimate. > > > > Check for this case up front in folio_check_splittable and return > > -EBUSY before any state is modified, so the split routine always backs > > out cleanly. > > > > Also fix a bracket style issue that checkpatch.pl keeps complaining > > about. > > > > Fixes: 00527733d0dc ("mm/huge_memory: add two new (not yet used) functions for folio_split()") > > Fixes: 714b056c8321 ("mm/huge_memory: convert VM_BUG* to VM_WARN* in __folio_split") > > Reviewed-by: Zi Yan > > Signed-off-by: Kairui Song > > --- > > mm/huge_memory.c | 27 ++++++++++++++++----------- > > 1 file changed, 16 insertions(+), 11 deletions(-) > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index ced400f72d43..a6759a14e057 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -3878,6 +3878,9 @@ static int __split_unmapped_folio(struct folio *folio, int new_order, > > int folio_check_splittable(struct folio *folio, unsigned int new_order, > > enum split_type split_type) > > { > > + bool is_anon = folio_test_anon(folio); > > + bool is_swapcache = folio_test_swapcache(folio); > > Both const please. I see a lot of const everywhere in mm code now. I feel I missed the memo. Do they make a difference? I was relying on "Compiler does its job"(TM) for things like this before. -- Kiryl Shutsemau / Kirill A. Shutemov