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 C6CE138758D
	for <linux-kernel@vger.kernel.org>; Mon, 10 Aug 2026 17:20:36 +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=1786382437; cv=none; b=eyJEoOuNab8l7WlMCxkeFp271yoEBa3500QmX15GY9KpAZVC7YEuhyx09iE0aLj7BBeq7X4t+WJryn3r/9s7iG1yLQXdS2f+dsgAJG7ZH9qTEmxL2A7l1ly20MiW7GgEbRadW+P14LDYfWaeMI7ZRBl69SgvQImPkh6vlQAFgOM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1786382437; c=relaxed/simple;
	bh=Jzkh0ze8tAOXTG6Oneq40RhilasAUM0kAhFZOJxtyLQ=;
	h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References:
	 Mime-Version:Content-Type; b=dIpjj2dxPpGJwc5PD/IckCt9+Uj0WhCq5CZpYTFllv2XamC6CFAqAL+cxrkBK/IQsXoW8oQTAL50UuV0mMOdXWsLIthQbgD9uqgYRFbTj+hi73Ch1QktMJz1Gk9P3cEo3Q9ZhirkMwUKYNg3iHHi1UatZ68m6wd/yUy4TwMhKWA=
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=yHDWZ4xX; 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="yHDWZ4xX"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8CCAC1F000E9;
	Mon, 10 Aug 2026 17:20:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=korg; t=1786382436;
	bh=fWx0toGzjy2ZbdJGqHeiMNuTjd9QpxmERukNiIPTFMA=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References;
	b=yHDWZ4xXBKoArGvbqzbMAA/tNo0o9COtH41cg8cn6woKudtLFzs/P+97G9pzHxCQ7
	 B2WM790UiMC9K5I/iXFP83/r0QS3unyXVPY/+gV1pQv2mvRD+2Y1ReTawhoG/hMpOF
	 +4a7T6zYWszbe4BK5D2PgAWcVEmP/PwXTwYN3Uho=
Date: Mon, 10 Aug 2026 10:20:34 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Breno Leitao <leitao@debian.org>
Cc: Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>, Kemeng
 Shi <shikemeng@huaweicloud.com>, Nhat Pham <nphamcs@gmail.com>, Baoquan He
 <baoquan.he@linux.dev>, Barry Song <baohua@kernel.org>, Youngjun Park
 <youngjun.park@lge.com>, David Hildenbrand <david@kernel.org>, Lorenzo
 Stoakes <ljs@kernel.org>, "Liam R. Howlett" <liam@infradead.org>, Vlastimil
 Babka <vbabka@kernel.org>, Mike Rapoport <rppt@kernel.org>, Suren
 Baghdasaryan <surenb@google.com>, Michal Hocko <mhocko@suse.com>, Jann Horn
 <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>, Hugh Dickins
 <hughd@google.com>, Baolin Wang <baolin.wang@linux.alibaba.com>, Peter Xu
 <peterx@redhat.com>, Johannes Weiner <hannes@cmpxchg.org>, Yosry Ahmed
 <yosry@kernel.org>, Chengming Zhou <chengming.zhou@linux.dev>,
 linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH 0/3] mm, swap: don't spin or flood the console on a bad
 swap entry
Message-Id: <20260810102034.547699380bbe7aeb232344a9@linux-foundation.org>
In-Reply-To: <20260810-swap-v1-0-375ef0767206@debian.org>
References: <20260810-swap-v1-0-375ef0767206@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: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 10 Aug 2026 09:26:48 -0700 Breno Leitao <leitao@debian.org> wrote:

> I've seen some machines at Meta flete 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 tha.
> 
> 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:

Thanks.  Sashiko said a bunch of things, all pre-existing.
	https://sashiko.dev/#/patchset/20260810-swap-v1-0-375ef0767206@debian.org

You might wat to address the first one as it's on-topic for this
patchset.  Ther are some swap things.  The remainder are for the poor
uffd maintainers to scratch at, if inclined.