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 ABBE8390229 for ; Mon, 17 Aug 2026 12:22:16 +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=1786969338; cv=none; b=JufMi0xNOeLAHQUEJHpTNZlZhghiYaq/0dxGVHQUaxM6ozVRyaw3vPUlAFomRcbbjVjOx6wYLv2TdL6OghoR9af/QkQpV7cRlDg7KHgi3GbCTNZJ+8F+8EZ3fKp58BodrulVG/wGgYOIvDeSLe7wgUP7FJsbGXl9FsRD3WAZvsk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786969338; c=relaxed/simple; bh=Rps0RgD/IP5G9PEnYAb/tsSeXgSvAAPxt7/LIuNYSrs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=O48Ym/8uDVk4KDW/u/v2XjySVei3d2AV7FXKGEx/Z4XUi/sGdb8O2nF1SkiCp8rvuQBrko5qmseDh3MnmCaGhnw+n2k+68DgUgsgwaikEPEPoZh9gJEB7GfATYOkLXWAmQLTEa9anXgQDclPptqC9E4WqjHa4FvyLXdUWWC+9zk= 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=SJIrd9Vl; 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="SJIrd9Vl" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=IcRuYbDemapntKxkxm0nYno5F87CmpF/VTX8mqgRBG4=; b=SJIrd9VloOXaqMpJtvhltKrkl2 iTbsrl1WsIGdJHF90ymVAuIjTCPKK2ZOjJc5PI8EtfGnSQ6HS3FJpx+uc0SxH2ms3jJXssrH/kK6Y eyd0FW39IH9MrtDv7N503H+ojnNfT8sPGwxoEe63BZsaVWrm7aV3ldi3Np+9XaBqyGobQp6eHdLGx +mJ2jH7woPjueWyCm0oEHu/UubQEkOrZjER2qkT7P0oDTUGFKXb0Rh4V+hv4Xq+IPC4IymxTzA8FL 3roTeSHSo5CWIlBP8nkJrtd37M27j2FL9fOs5FSJWbE7MrGLtbrRYACjpi05JW/Vof/SBLqLreZWW WQGye5YQ==; 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 1wvwLS-008DhQ-34; Mon, 17 Aug 2026 12:21:39 +0000 Date: Mon, 17 Aug 2026 05:21:32 -0700 From: Breno Leitao To: Andrew Morton Cc: 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 , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v2 0/3] mm, swap: don't spin or flood the console on a bad swap entry Message-ID: References: <20260813-swap-v2-0-4a625ccabdae@debian.org> <20260813133455.3fe770eadcbe640e6f6c46cb@linux-foundation.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: <20260813133455.3fe770eadcbe640e6f6c46cb@linux-foundation.org> X-Debian-User: leitao Hello Andrew, On Thu, Aug 13, 2026 at 01:34:55PM -0700, Andrew Morton wrote: > On Thu, 13 Aug 2026 03:02:19 -0700 Breno Leitao wrote: > > > 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: > > Cool. > > These behaviors sound pretty obnoxious. And the patches are quite > simple so hopefully the swap maintainers will make quick work of them. > > I'm assuming that users of earlier kernels will want these things fixed > so please let's work on identifying suitable Fixes: targets and > deciding which of them should get a cc:stable. > > > > In a spirit of experimentation I asked Gemini to identify suitable Fixes: > targets and it said > > [1/3]: Fixes: 122e201211e4 ("mm, swap: get_swap_device() to get reference count of swap_info_struct") > > [2/3]: Fixes: 122e201211e4 ("mm, swap: get_swap_device() to get reference count of swap_info_struct") > (and it complained that this patch doesn't fix anything) > > [3/3] Fixes: 122e201211e4 ("mm, swap: get_swap_device() to get reference count of swap_info_struct") > > And I cannot find such a commit anywhere, so wtf. I think only 1/3 should be getting a Fixes: in v3. The message I am drowning in is the Bad_offset one: get_swap_device: Bad swap offset entry 3ffffffc043c5 63d8620ecf93b5 ("mm/swapfile: use percpu_ref to serialize against concurrent swapoff") added the put_out: label with just the percpu_ref_put(), so that arm was silent. The pr_err() landed in v5.19: So, if I need to update it, I will include: Fixes: 23b230ba8ac3 ("mm/swap: print bad swap offset entry in get_swap_device") Cc: > [2/3] is "no functional change" so ideally it simply wouldn't be > present in the series - we should aim for minimal changes when fixing > bugs, then leave the cleanups for later. I need 2/3 to expose the difference in the first place. get_swap_device() returns NULL both for a malformed entry and for a device swapoff is taking away, so no caller can tell whether the failure is worth retrying. 2/3 adds that distinction and converts the callers, but none of them act on it yet, so it is no functional change on its own. Then 3/3 is the actual fix, now that do_swap_page() can differentiate a retry from give up. Do you want me to squash them?