From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D1A5923AE87 for ; Wed, 17 Dec 2025 01:04:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765933462; cv=none; b=pa+TbADpd4NoE35kn0nHQhlgclJTbFAkNYWw/DS/Ss06qmqYmZlVslrSgMtotAX6EIthxr0kTBwAB1sX+ELUf/jYvzkRnQA0Cn8ko5v1lFYn3OtH7sV6i1ZYRYWTRK/jpkKQ6291zL0R8rak2qbnlptZApjoJqwDm4RmRPFPYfg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765933462; c=relaxed/simple; bh=mMXmHQ7csVVs/pqngM3zcYY3/VLMqlnXZgjxMihN4jQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bByZg2LkDfFrNGXvCQ0woQLK1vlk0TvkEXwVKYVMPIRVDHKXGzsxGeEflgS16XmV+EmhrHTCzmUrbyvPVAMmiqeuIBWPF6KFGprnwceG8yjL3U/XpIGO1mQHxEIKmWR9QkGQlQzukOFEhE8tmesHCm88j7DqfXT8SNPDRXDjJCE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZCQGuh9c; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZCQGuh9c" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2CCEC4CEF1; Wed, 17 Dec 2025 01:04:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765933462; bh=mMXmHQ7csVVs/pqngM3zcYY3/VLMqlnXZgjxMihN4jQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ZCQGuh9c7Xu3acTV1Pfs2wZHylukIvLXKSjT76xZ9+QzUh2RlFczM2CUz6XLfGLbv w+vzf3XOvh/lBf49Q1KR8PTFSKl3GBK/9QxEVstLa/QOKgN79rdLWGkiiFyOmclXk2 uS4lUWzddnrBxgbGqrBOAbI4n0vzGccERLhiSMOIanX3UzefgYznnqkFP3mQ8c7pCj J2KEqaO/4p+dywxTISgfR4R+SqDvbFS8BDEIX62XBXgKlJM3jT+WACBZoy43Hosuta 1X14Y3MRX13PuNALqJxuz7vFQ/Q97ITROy9HgHzx34qxYWbOu3nDa9AASdlPU4xCft 0GvqCJ6S4820g== Message-ID: Date: Wed, 17 Dec 2025 02:04:16 +0100 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] mm: Consider non-anon swap cache folios in folio_expected_ref_count() To: Zi Yan , Bijan Tabatabai Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, shivankg@amd.com, Baolin Wang , Hugh Dickins , Chris Li , Kairui Song References: <20251216200727.2360228-1-bijan311@gmail.com> <6b4cadb2-6246-48cc-9c76-64ba0a23198b@kernel.org> <0C218C18-916B-4BB0-8B37-AC82503E4AD9@nvidia.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <0C218C18-916B-4BB0-8B37-AC82503E4AD9@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit >>> >>> I am not very familiar with the memory hot-(un)plug or swapping code, so >>> I am not 100% certain if this patch actually solves the root of the >>> problem. I believe the issue is from shmem folios, in which case I believe >>> this patch is correct. However, I couldn't think of an easy way to confirm >>> that the affected folios were from shmem. I guess it could be possible that >>> the root cause could be from some bug where some anonymous pages do not >>> return true to folio_test_anon(). I don't think that's the case, but >>> figured the MM maintainers would have a better idea of what's going on. > > I am not sure about if shmem in swapcache causes the issue, since > the above setup does not involve shmem. +Baolin and Hugh for some insight. We might just push out another unrelated shmem page to swap as we create memory pressure in the system I think. > > But David also mentioned that in __read_swap_cache_async() there is a chance > that anon folio in swapcache can have anon flag not set yet. +Chris and Kairui > for more analysis. Right, when we swapin an anon folio and did not map it into the page table yet. Likely we can trigger something similar when we proactively read a shmem page from swap into the swapcache. So it's unclear "where" a swapcache page belongs to until we move it to its owner (anon / shmem), which is also why I cannot judge easily from [ 49.641309] migrating pfn b12f25 failed ret:7 [ 49.641310] page: refcount:2 mapcount:0 mapping:0000000033bd8fe2 index:0x7f404d925 pfn:0xb12f25 [ 49.641311] aops:swap_aops [ 49.641313] flags: 0x300000000030508(uptodate|active|owner_priv_1|reclaim|swapbacked|node=0|zone=3) [ 49.641314] raw: 0300000000030508 ffffed312c4bc908 ffffed312c4bc9c8 0000000000000000 [ 49.641315] raw: 00000007f404d925 00000000000c823b 00000002ffffffff 0000000000000000 [ 49.641315] page dumped because: migration failure What exactly that was. It was certainly an order-0 folio. [...] > > I agree with David. Acked-by: Zi Yan Thanks for the fast review :) -- Cheers David