linux-kernel - Re: [PATCH v9 0/2] mm/vmscan: fix demotion targets checks in reclaim/demotion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aWniFUZgiuNEDe9O@google.com>
Date: Fri, 16 Jan 2026 07:00:37 +0000
From: Bing Jiao <bingjiao@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: David Hildenbrand <david@...nel.org>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Michal Hocko <mhocko@...e.com>,
	Axel Rasmussen <axelrasmussen@...gle.com>,
	Yuanchu Xie <yuanchu@...gle.com>, Wei Xu <weixugc@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Qi Zheng <zhengqi.arch@...edance.com>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Gregory Price <gourry@...rry.net>,
	Joshua Hahn <joshua.hahnjy@...il.com>, muchun.song@...ux.dev,
	roman.gushchin@...ux.dev, tj@...nel.org, longman@...hat.com,
	chenridong@...weicloud.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org
Subject: Re: [PATCH v9 0/2] mm/vmscan: fix demotion targets checks in
 reclaim/demotion

On Thu, Jan 15, 2026 at 04:00:11PM -0800, Andrew Morton wrote:
> On Wed, 14 Jan 2026 20:53:01 +0000 Bing Jiao <bingjiao@...gle.com> wrote:
>
> > I’m resubmitting the full refreshed patch series together this time.
> > I just realized it is better to include the unmodified patches alongside
> > the modified ones to ensure compatibility with upstream automated tools
> > and to simplify your review process.
>
> No probs.
>
> [1/2] is cc:stable whereas [2/2] is not.  Ordinarily that means I must
> split the series apart (they take different routes) and often discard
> the [0/n].

Hi Andrew,

Thank you for the explanation. I appreciate the insight into the upstream
process and the time you have taken to review this series. I wish I had
known this earlier so as not to add to your workload.

> In this case I think I'll leave things as-is, so [1/2]'s entry into the
> -stable pipeline will occur a few weeks later.  I don't think the
> problem is serious enough to need super-fast-tracking?
>
> Hopefully this approach means we'll get some Reviewed-bys ;)

I agree that the issue does not require urgent fast-tracking, so leaving
the series as-is for the standard pipeline is appropriate.

Best regards,
Bing