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: <aEyyF9SsTGguEBGd@visitorckw-System-Product-Name>
Date: Sat, 14 Jun 2025 07:19:51 +0800
From: Kuan-Wei Chiu <visitorckw@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Robert Pang <robertpang@...gle.com>, corbet@....net, colyli@...nel.org,
	kent.overstreet@...ux.dev, 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 Fri, Jun 13, 2025 at 11:04:15AM -0700, Andrew Morton wrote:
> On Fri, 13 Jun 2025 23:26:33 +0900 Robert Pang <robertpang@...gle.com> wrote:
> 
> > Hi Andrew
> > 
> > Bcache is designed to boost the I/O performance of slower storage
> > (HDDs, network-attached storage) by leveraging fast SSDs as a block
> > cache. This functionality is critical in significantly reducing I/O
> > latency. Therefore, any notable increase in bcache's latency severely
> > diminishes its value. For instance, our tests show a P100 (max)
> > latency spike from 600 ms to 2.4 seconds every 5 minutes due to this
> > regression. In real-world environments, this  increase will cause
> > frequent timeouts and stalls in end-user applications that rely on
> > bcache's latency improvements, highlighting the urgent need to address
> > this issue.
> 
> Great, thanks.  Let's please incorporate this into the v2 changelogging.
> 
> > > > 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.
> 
> "much safer and smaller" is very desirable for backporting, please. 
> After all, 866898efbb25 didn't really fix anything and reverting that
> takes us back to a known-to-work implementation.
> 
> I of course have no problem making the changes in this patchset for
> "going forward"!
> 
> So if agreeable, please prepare a patch which reverts 866898efbb25. 
> Robert's words above are a great basis for that patch's description.
> 
Sure, I'll prepare a revert patch to address the issue and plan to
submit it for backporting to -stable.

However, I'd like to confirm whether the following patch series
structure would be appropriate:

- Patch 1: Revert 866898efbb25 and CC it to stable
- Patch 2–8: Introduce the new equality-aware heap API
- Patch 9: Revert Patch 1 and switch bcache to use the new API

In this case, we would only backport Patch 1 to stable.

Alternatively, would you prefer we simply revert 866898efbb25 without
introducing and using the new API in the same series?

Regards,
Kuan-Wei