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 4DF27C71136 for ; Tue, 17 Jun 2025 22:59:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 784486B007B; Tue, 17 Jun 2025 18:59:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 735676B0088; Tue, 17 Jun 2025 18:59:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64B4A6B0089; Tue, 17 Jun 2025 18:59:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5938D6B007B for ; Tue, 17 Jun 2025 18:59:01 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C842F16122B for ; Tue, 17 Jun 2025 22:59:00 +0000 (UTC) X-FDA: 83566409640.07.867AB7B Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf20.hostedemail.com (Postfix) with ESMTP id 33B141C0006 for ; Tue, 17 Jun 2025 22:58:59 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=IxN6J0bq; spf=pass (imf20.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750201139; a=rsa-sha256; cv=none; b=4np7K/WyUotmUc9azDE0zWPZtTe0KDRkFjUq1gPTYw8KSnV5dmptNuqp8nK9YySz71RAFz ieONq5V26ZtbTYRl7CS7gcsg9WMQI0KVStOEtVzurOR/hHYSo9CjS75/hptjVhsrDkIN4N tSaX/lJNm31zLfmVjuvqxrVP7NQ28fE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=IxN6J0bq; spf=pass (imf20.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750201139; 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=mlg4cWCI0EuzYKc7RjEPMDpGOgQoZs8s1+qMJBR0ZuE=; b=VsBH79+q/RAWv3nnBx2eGSHdVE40WBN4K2p2CTAC6aN9pNeNWZnvJbeuVYZypTvflMWza8 BwoWojWE8qwFv3QvmZCGOAn72ibpEKpwPDcQrpJ45MpDJgK8tDkKQxP7nHbFf7HP8q8sdl B/r0fWHf8kCnwtkEfgmeVEHJcyAI53w= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 6F62F614BC; Tue, 17 Jun 2025 22:58:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0424C4CEE3; Tue, 17 Jun 2025 22:58:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1750201138; bh=Om8rU9t5dO6lsVh6MDdI4iXYo/zn/c0NhqCeM4oAPP4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IxN6J0bqVg7BJzBziBGOF397Zd96J+vvx3GuCJn5LqjbbZjt3Gj2osEU4aL/xU2ei 8WlruCNvsN48JduOcNc6N7qH95OxfU10NC7WoOBRDqRkiYur+BXwSveUNNy21vlbrt mOhtYMjMTuQOLLZ7So9QyrYFMsqHLQtY4vPT50aE= Date: Tue, 17 Jun 2025 15:58:57 -0700 From: Andrew Morton To: Kairui Song Cc: Kairui Song , linux-mm@kvack.org, Hugh Dickins , Baolin Wang , Matthew Wilcox , Kemeng Shi , Chris Li , Nhat Pham , Baoquan He , Barry Song , linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 1/4] mm/shmem, swap: improve cached mTHP handling and fix potential hung Message-Id: <20250617155857.589c3e700b06af7dff085166@linux-foundation.org> In-Reply-To: <20250617183503.10527-2-ryncsn@gmail.com> References: <20250617183503.10527-1-ryncsn@gmail.com> <20250617183503.10527-2-ryncsn@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 33B141C0006 X-Stat-Signature: 6jzybj65wy3874ggbz83xep8p995yqwg X-Rspam-User: X-HE-Tag: 1750201139-366928 X-HE-Meta: U2FsdGVkX1+c7GAlG9rt2rkrLfvIIJbhV3p5do/hf5F7clqd5jnLkRvIP0t3wASn74WtkYIAaVU8T3Tq2DcW68W/vTApdKGa+JCA9LT80HSLQnSZPxXShFJVnNkUYqWSu6rojKyjovUQ4l4ueCVciWx+ngskAIF8FCIhlsmB/TiU4Pir932s/Ozf3EAUmQzKXKbVgESrIcxV39omokyyPYqlC2zHbyO841ZJa4NZwq2wMaWgGVdMwjOPHMS86K3eGSCXroBpUh4fV+Pru5FH6FmFKMfvtCElyPYmU31kikVVpzeepkaIRmc4Xw5cuyXQMhZrl4hbxpoCOAgHufYVyX3HRBzcRdWEyib7wtYiCwqHeNOo0WOQY4uIItPx6tljotR1Fqzl+6SB6kQKY3zGtEa0G4TxCDxP3TWQF7WEo0nbIxGibjsa8R1kvwAvaX3eUpDKh9rVMnFg/IoFuKGsVMM+3RZNW1oZhLq59jETwpOvqH8Hq9G+bc+uS0tCzdD5TEyel3YaQB6hCYN87gWsNEwb0k5RUvY8ZAf7AtEZR4JVKOG+HzwBKAxa7G/gdc43tR/B26A29InCDJqgHFVsa2ftkR8cXUyBWzjCRTwQavI/DuTz7Q3pNRdb3M75J+kaEOxapnH/ZgxXR4xISRiiuybRaHmIuE3x0abY1zLZvMURh5Z3pLGuLnIYlLMDktkvAOwlWA2GgI1ChB3nfpv6L0xormygMmiz0mlio9WJpKk80fjiblU+CnPx4KQpPx6i3ZSaAAXHq263s772yNp4bh2mb3wMQcMz7f8Qc7st7BOBbkazk7ueRNQBBrgojy8zkROUkhE16+7wnNaPfHBEwqU7mnGfyuYlYkbYvR+Tquo2uPJ7qmTV0MSHieMa9TDjrTF+uEbAWCCQ/HJIgwH96JD7s+qRi6mG6EqMVPWui2+kNqEwSjvZd57F4j9aGlwttlPd/K3U9b8pRgQLHC/ i5MoWe7J MwGTni8qjEqIY/2haFt0LiprWaonKn/P5XTHctjEMUi4Tq4QAjONdH5cMi1b9QaiFO2OGoFZqui5JxZX3GS5StlDI6x+qECTiJaM4Ey0GN2yXD5xbli6TomBQFQn5n2qtBXxoXqVl+QwfpA8HC3YNBsALGXu66CWDdp0mAMeicaSOlqa4oTnxJHWIkEd6tD7jx9OjHV0hWBFdnJ7V/cyBBa16SqA1KckqRY0iceLe2pNlSgoH4seolJlT58njFxh8/3AykOf4ea0XYir5EaFqkSrJY9r11RgcSy7181wPsJBQpWR7nto9/eB4X5+FnftfbKRu X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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, 18 Jun 2025 02:35:00 +0800 Kairui Song wrote: > From: Kairui Song > > The current swap-in code assumes that, when a swap entry in shmem > mapping is order 0, its cached folios (if present) must be order 0 > too, which turns out not always correct. > > The problem is shmem_split_large_entry is called before verifying the > folio will eventually be swapped in, one possible race is: > > CPU1 CPU2 > shmem_swapin_folio > /* swap in of order > 0 swap entry S1 */ > folio = swap_cache_get_folio > /* folio = NULL */ > order = xa_get_order > /* order > 0 */ > folio = shmem_swap_alloc_folio > /* mTHP alloc failure, folio = NULL */ > <... Interrupted ...> > shmem_swapin_folio > /* S1 is swapped in */ > shmem_writeout > /* S1 is swapped out, folio cached */ > shmem_split_large_entry(..., S1) > /* S1 is split, but the folio covering it has order > 0 now */ > > Now any following swapin of S1 will hang: `xa_get_order` returns 0, > and folio lookup will return a folio with order > 0. The > `xa_get_order(&mapping->i_pages, index) != folio_order(folio)` will > always return false causing swap-in to return -EEXIST. > > And this looks fragile. So fix this up by allowing seeing a larger folio > in swap cache, and check the whole shmem mapping range covered by the > swapin have the right swap value upon inserting the folio. And drop > the redundant tree walks before the insertion. > > This will actually improve the performance, as it avoided two redundant > Xarray tree walks in the hot path, and the only side effect is that in > the failure path, shmem may redundantly reallocate a few folios > causing temporary slight memory pressure. > > And worth noting, it may seems the order and value check before > inserting might help reducing the lock contention, which is not true. > The swap cache layer ensures raced swapin will either see a swap cache > folio or failed to do a swapin (we have SWAP_HAS_CACHE bit even if > swap cache is bypassed), so holding the folio lock and checking the > folio flag is already good enough for avoiding the lock contention. > The chance that a folio passes the swap entry value check but the > shmem mapping slot has changed should be very low. > > Cc: stable@vger.kernel.org > Fixes: 058313515d5a ("mm: shmem: fix potential data corruption during shmem swapin") > Fixes: 809bc86517cc ("mm: shmem: support large folio swap out") The Fixes: tells -stable maintainers (and others) which kernel versions need the fix. So having two Fixes: against different kernel versions is very confusing! Are we recommending that kernels which contain 809bc86517cc but not 058313515d5a be patched?