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 3EB2B3ACA6E
	for <linux-kernel@vger.kernel.org>; Mon, 17 Aug 2026 21:53:38 +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=1787003620; cv=none; b=K6SdRj/S8AQCKofD9RxAYU2FmKc3y+hcJeyX3byuhgqWrQiZwgqGjGNBI2ZBFOU2fmngLbONj/R9vEo5TLcL8Q4I+cwgUNnc0iUaYaTvcByVDs/PT/dyigTh/AxIjhmNC8MMwTStkCKYjmONLhjSFrkurX95Kadtcz7tw0A3h4U=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1787003620; c=relaxed/simple;
	bh=rjWzM8nVu0a0aWyXj+XVe1S18THrKrFMkc0puoHARUg=;
	h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References:
	 Mime-Version:Content-Type; b=fHwfbzA8LI0K0aJSXzmg6lAO6OYufEBLjvegIaqP8FuGU7mOgol1lOnGBdjY11xjoSCDFUdEGWQ7cr67D8JzS0hhGFCqEDGLqWqHmxqRubtiiQwo6mK+5s4mBGygiW0/+dAnUsN8Gi47F729KuchcoFdmEh6P4FonGdUsH/JgmA=
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=rYJfVdrJ; 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="rYJfVdrJ"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11C0D1F000E9;
	Mon, 17 Aug 2026 21:53:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=korg; t=1787003618;
	bh=QFdvYbnSNaDyaig6V7v5E+8daoEbZSeLkM7vwKbiaF4=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References;
	b=rYJfVdrJRxl3lQ79a0HsX9L2ErzbiqR7gwqtPnZhh375GKWvnMSsMXepJ5zuViQEw
	 TyuraXGEUdfigTfoKbVUclnHfk4Ap2l2nMwZSYuEogPjnavE0lt79oPBjIDSABfhTQ
	 9aq6LmuXxiX34obmbaW7O9F6+Arnw8TjMx1lZ0Sk=
Date: Mon, 17 Aug 2026 14:53:37 -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 v2 0/3] mm, swap: don't spin or flood the console on a
 bad swap entry
Message-Id: <20260817145337.85c945fbfc7e8165ea016710@linux-foundation.org>
In-Reply-To: <aoL2hgmgQYk8vU8i@gmail.com>
References: <20260813-swap-v2-0-4a625ccabdae@debian.org>
	<20260813133455.3fe770eadcbe640e6f6c46cb@linux-foundation.org>
	<aoL2hgmgQYk8vU8i@gmail.com>
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, 17 Aug 2026 05:21:32 -0700 Breno Leitao <leitao@debian.org> wrote:

> 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: <stable@vger.kernel.org>

OK, so you think that only [1/3] should have cc:stable?

> > [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?

If I'm correct above then please send along [1/3] as a separate thing
and I can queue it as a backportable hotfix.  Then [2/3] and [3/3] as a
separate two-patch series for 7.3-rcX.