From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 85564374E48 for ; Thu, 13 Aug 2026 20:34:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786653298; cv=none; b=pEQ1pc6oYun2YCRrEMC2IjB1n1TYMI3Ce1yMcAuNUX53AOVoVC27w48eoC5l7jd0iyUjFclfTYImslV1iZijNMALuZDU7chRqKk3UvCvWzbdE8jGUT/qRzVdSlE/J3JGXb8ZagPHySMwqzy7z4+ypJXGKx76AOBfV0m1qmJnKHk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786653298; c=relaxed/simple; bh=yx0hJSkKUxZg9lJ5MhvwRAqXhZlOBOiGdDBmjMOS5S4=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=ck8X/2B2wfuZ0rqwIxxW58lbScNh3SVBfhrYY19/fHzD6Hab/fp2ORioRP+BvHm+DRz9JpldMA0FkAATSWsavMB/qxvAwrjqGO9z+/DiW7ktfbHlEMGy2xJ8EZInhwJzIFjRCpCGYDtGg4fZjxtA5wlO2rP4/WmgivaYDDqWF8I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=zG+Mz8wA; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="zG+Mz8wA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 392BC1F000E9; Thu, 13 Aug 2026 20:34:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1786653297; bh=S6cmsqG8l1zHA7G2eW50R84mRNDy78OB/Hf6CViIuCI=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=zG+Mz8wAESaFgbRTNpUhV5gDm1QDClFyEh8Ovhvu0WoDTePb2+EvDHSn2FKcngIFO /LnfoOA25EiRjyARMHAT9ior6KhjydG7NBn4AsaTh5TVr/nVSDXdRRuTRpSYVMSH7C CZ/umvUuoFSCA4o+YF4WQPd7dsNJAnSldnbng/zQ= Date: Thu, 13 Aug 2026 13:34:55 -0700 From: Andrew Morton To: Breno Leitao 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: <20260813133455.3fe770eadcbe640e6f6c46cb@linux-foundation.org> In-Reply-To: <20260813-swap-v2-0-4a625ccabdae@debian.org> References: <20260813-swap-v2-0-4a625ccabdae@debian.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit 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. chatgpt didn't give me anything useful. [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. > 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. Yeah. probably these are the same issues: https://sashiko.dev/#/patchset/20260813-swap-v2-0-4a625ccabdae@debian.org As usual, they're all mishandled error-path things. It's axiomatic, really - nobody hits error-path bugs, so they never get reported so they never get fixed. otoh, now that these bugs are out there and known about, it's possible that a Black Hat can find a way of exploiting them, which increases the pressure to get these bugs addressed.