From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 D24C6442FC5 for ; Thu, 13 Aug 2026 10:02:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786615375; cv=none; b=N3yn/X7kGQ2uuvJISiGUYA39mD5He2V4rGnAlKjRkMOA327OXznQt9mAEJlVA8vPGBk4D8YUafgeeh7djkyhhc7AlIdCVc6dfMlgQJ+o3YH6tKNkYW+yEM3k7NPQBIiGK0yqCKPbVR1mYbH8834Dwys08eEIpEIhr5ZAQxnshTk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786615375; c=relaxed/simple; bh=P+JzP1CqEXHUFbZL8c3/vL+HspDOATmKqPkkB46OJ2I=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=p6S3zB6pF4y6pazu37TDfp74oV/sXAkQzRXZHxcO2Z7wYbwZLucmVwE6qKTca5cu+QNYcnxDBVYnP++dWu812cev+n0ouhrIpzjeJ/l8GoI3gP3Q9LWvzoKss3tBzWl0AJWyzUvJCmTPoeR/YMQVNYQ+xxPg6lUod9Ald+qZpmo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=ay/LPQbs; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="ay/LPQbs" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Cc:To:Content-Transfer-Encoding: Content-Type:MIME-Version:Message-Id:Date:Subject:From:Reply-To:Content-ID: Content-Description:In-Reply-To:References; bh=1G3eQpvA85JuAZzs61f9HPusHslY0rOubeUY5om3sZ4=; b=ay/LPQbsQM/RRgnxq7bAHdUMvQ f8Jw5AU1r5nZdi+WwygDbYVnhSRQiTpk6KnQ1TbMbn+5sMSSr4zM2sHdw73BusaAkR9xt3kwT2rLe HkRhn3grScRyWf0nAkVw8V5X+lClhsAwNr2BUSrO0rBT7xE8PCQjqsI12fSumqZouosXMnbFO37X1 +NCJ55dINFEnVtfnNLiyuoC1T2KagbEG3AoV4M55JYbHs2gUKQUrl4viI8XEUFeT2eRhYbyGwWOKb ucpGw/XWYvEbyh6YFTBnX2rDR78EQ8CE8i6cNtmjv7bnnAa0a7q+qkPIgUiq/FulACSdMRo6QGVKL +pAUd05Q==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wuSGc-00520I-2b; Thu, 13 Aug 2026 10:02:31 +0000 From: Breno Leitao Subject: [PATCH v2 0/3] mm, swap: don't spin or flood the console on a bad swap entry Date: Thu, 13 Aug 2026 03:02:19 -0700 Message-Id: <20260813-swap-v2-0-4a625ccabdae@debian.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="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIACuWfWoC/13MsQ6CMBAA0F9pbm7N9ZQWOvkfhqHAAbcAaQ1qS P/dyOj6hndA5iScIagDEu+SZV0gKNIK+jkuExsZICggJIe1RZNfcTNU3QjHpq+72IBWsCUe5X0 2j1YrmCU/1/Q5193+9C/YrUFz9RWP6J0ndPeBO4nLZU0TtKWUL1w1CNKZAAAA X-Change-ID: 20260810-swap-25420f9c8ba9 To: Andrew Morton , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , Hugh Dickins , Baolin Wang , Peter Xu , Johannes Weiner , Yosry Ahmed , Chengming Zhou Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Breno Leitao X-Mailer: b4 0.16-dev-f8e9d X-Developer-Signature: v=1; a=openpgp-sha256; l=4056; i=leitao@debian.org; h=from:subject:message-id; bh=P+JzP1CqEXHUFbZL8c3/vL+HspDOATmKqPkkB46OJ2I=; b=owEBbQKS/ZANAwAIATWjk5/8eHdtAcsmYgBqfZYwoXTW5JqGMoaPfGNKdYcL8kANbO9Q4Ubo3 flR7Y+Hk+2JAjMEAAEIAB0WIQSshTmm6PRnAspKQ5s1o5Of/Hh3bQUCan2WMAAKCRA1o5Of/Hh3 bZy6D/9+FHGROjiGe5DGGfeuJczbW1nUEpKTdTwXe46MRshMrZZPN4KTb425BppzxmDgHhmbe9O lMR9pGroA3tkvg8EzRTIkCwLPNf1vV/tB+MDWUriJLOQfoYFwRHGI8YhQDdm+NlzNkkLeBemZ7P YUjpLqg4n4+m4z6cvyQ2EZllu3jId9C9Qr6a9BJlzLRKLWEnlhtZggto1Zkq7f2TH7A+DIQ9uyk 7BDyHdg/WyQAdu6YD64uo0qh4aokah3GyE5EzYsexvSElNzUupfMo7Vu1MDQ/OHlFcMtWYC+A3C Qn1IbycDeMTZCJ5MB8VdC/NQq/jcu2L5CryvQeW/2Tth+Av5IzkaKqtYbd1IY7IOgLuGMzhDJ7H CpxGZ6t05Q5Vk4w5Ch34u3ctBJ7AxstISCwRVSZrJ0xP1IRykloHe5NzbmHyHAawtoXp5fcaU96 a7DgSfEwnEEAyfrW7CNkvbBRFPu9nX+AFBiU9lzNjUED9uFm2xj5L0hYwwfNQyxTaQBrzFEECaK +Q0L8lsfDR2qGz8QoCbZ9+azG4WKeVV85ZUAQGhyHwAkUYf1AElEgHGqPGcdP73vnuBOqrnX9Vv 2rt96dILyXeVFsv3Dilw+SlxPaWYpug4WKVxSPrU5Nmezt0zwwKboyZKasvJWK+yTw2mnZCtyJJ M7IowvzndkEqPmQ== X-Developer-Key: i=leitao@debian.org; a=openpgp; fpr=AC8539A6E8F46702CA4A439B35A3939FFC78776D X-Debian-User: leitao I've seen some machines at Meta fleet that show the following type of problem: 1) It gets some weird warning: BUG: Bad page map in process khugepaged pte:f000eef300000017 pmd:00000067 addr:00007f57c0a01000 vm_flags:20200073 anon_vma:ffff88829af7c340 mapping:0000000000000000 index:7f57c0a01 The corruption is most likely the collapse/PT_RECLAIM race fixed by commit 366a4532d96f ("mm: fix the race between collapse and PT_RECLAIM under per-vma lock"). But this series is not about this one. 2) Then it floods all the monitoring of the fleet, sending the same message in the loop, crashing the our fleet kernel monitoring subsystem (which is the part that I am interested in protecting) get_swap_device: Bad swap offset entry 3ffffffc043c5 For instance, in a host today it logged 6M in a few hours, and it is still going forever. Two things go wrong. 1) get_swap_device() prints unconditionally, unlike print_bad_pte() next door which suppresses itself with is_bad_page_map_ratelimited(). 1) do_swap_page() returns 0 when get_swap_device() fails, so the fault is retried, reads the same entry and faults again. Nothing in the round trip changes the PTE. Trying to fix it in a naive way: Patch 1 is super simple, and rate limits the two prints. Patch 2 makes get_swap_device() return ERR_PTR(-EINVAL) for an entry that can never name a slot on any device, keeping NULL for a device swapoff is taking away, and converts the callers. No functional change expected. Patch 3 uses that to return VM_FAULT_SIGBUS instead of retrying. PS: Sashiko flagged several pre-existing issues, and get_swap_device() returning an error opens the door to fixing some of them. For this series, I am focused in landing the basic cases first and build on top, if needed. --- Changes in v2: - Rate limit swap_dup_entry_direct()'s print too (Andrew) - Drop "in get_swap_device()" from patch 1's subject, it now covers all three prints - Return ERR_PTR(-EIO) rather than ERR_PTR(-EINVAL) for a malformed entry; -EINVAL is too soft for a corrupt page table (David) - Document the malformed entry case in get_swap_device()'s kerneldoc, in patch 2 instead of patch 3 (David) - Reword patch 2's changelog, "an entry that can never name a slot on any device" was unclear (David) - Link to v1: https://patch.msgid.link/20260810-swap-v1-0-375ef0767206@debian.org To: Andrew Morton To: Chris Li To: Kairui Song To: Kemeng Shi To: Nhat Pham To: Baoquan He To: Barry Song To: Youngjun Park To: David Hildenbrand To: Lorenzo Stoakes To: "Liam R. Howlett" To: Vlastimil Babka To: Mike Rapoport To: Suren Baghdasaryan To: Michal Hocko To: Jann Horn To: Pedro Falcato To: Hugh Dickins To: Baolin Wang To: Peter Xu To: Johannes Weiner To: Yosry Ahmed To: Chengming Zhou Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org --- Breno Leitao (3): mm, swap: ratelimit bad swap entry reports mm, swap: distinguish a malformed swap entry from a dying device mm: fail the fault on a malformed swap entry instead of retrying it mm/memory.c | 9 +++++++-- mm/mincore.c | 2 +- mm/shmem.c | 2 +- mm/swap_state.c | 4 ++-- mm/swapfile.c | 20 ++++++++++++-------- mm/userfaultfd.c | 3 ++- mm/zswap.c | 2 +- 7 files changed, 26 insertions(+), 16 deletions(-) --- base-commit: 6b8c8af514d739d0335f5579b585e02babe8a727 change-id: 20260810-swap-25420f9c8ba9 Best regards, -- Breno Leitao