linux-kernel - Re: [PATCH 0/8] Fix bcache regression with equality-aware heap APIs

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aEvCHUcNOe1YPv37@visitorckw-System-Product-Name>
Date: Fri, 13 Jun 2025 14:15:57 +0800
From: Kuan-Wei Chiu <visitorckw@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: corbet@....net, colyli@...nel.org, kent.overstreet@...ux.dev,
	robertpang@...gle.com, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-bcache@...r.kernel.org,
	jserv@...s.ncku.edu.tw, stable@...r.kernel.org
Subject: Re: [PATCH 0/8] Fix bcache regression with equality-aware heap APIs

Hi Andrew,

On Wed, Jun 11, 2025 at 06:48:17PM -0700, Andrew Morton wrote:
> On Wed, 11 Jun 2025 05:55:08 +0800 Kuan-Wei Chiu <visitorckw@...il.com> wrote:
> 
> > This patch series introduces equality-aware variants of the min heap
> > API that use a top-down heapify strategy to improve performance when
> > many elements are equal under the comparison function. It also updates
> > the documentation accordingly and modifies bcache to use the new APIs
> > to fix a performance regression caused by the switch to the generic min
> > heap library.
> > 
> > In particular, invalidate_buckets_lru() in bcache suffered from
> > increased comparison overhead due to the bottom-up strategy introduced
> > in commit 866898efbb25 ("bcache: remove heap-related macros and switch
> > to generic min_heap"). The regression is addressed by switching to the
> > equality-aware variants and using the inline versions to avoid function
> > call overhead in this hot path.
> > 
> > Cc: stable@...r.kernel.org
> 
> To justify a -stable backport this performance regression would need to
> have a pretty significant impact upon real-world userspace.  Especially
> as the patchset is large.
> 
> Unfortunately the changelog provides no indication of the magnitude of
> the userspace impact.   Please tell us this, in detail.
> 
I'll work with Robert to provide a more detailed explanation of the
real-world impact on userspace.

> Also, if we are to address this regression in -stable kernels then
> reverting 866898efbb25 is an obvious way - it is far far safer.  So
> please also tell us why the proposed patchset is a better way for us to
> go.
> 
I agree that reverting 866898efbb25 is a much safer and smaller change
for backporting. In fact, I previously raised the discussion of whether
we should revert the commit or instead introduce an equality-aware API
and use it. The bcache maintainer preferred the latter, and I also
believe that it is a more forward-looking approach. Given that bcache
has run into this issue, it's likely that other users with similar use
cases may encounter it as well. We wouldn't want those users to
continue relying on the current default heapify behavior. So, although
reverting may be more suitable for stable in isolation, adding an
equality-aware API could better serve a broader set of use cases going
forward.

> (Also, each patch should have a fixes:866898efbb25 to help direct the
> backporting efforts)
> 
Ack. Will do.

> 
> I'll add the patches to mm.git to get you some testing but from what
> I'm presently seeing the -stable backporting would be unwise.

Thanks!

Regards,
Kuan-Wei