linux-kernel - Re: [GIT PULL] bcachefs fixes for 6.16-rc3

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: <ep4g2kphzkxp3gtx6rz5ncbbnmxzkp6jsg6mvfarr5unp5f47h@dmo32t3edh2c>
Date: Thu, 19 Jun 2025 21:51:45 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Jani Partanen <jiipee@...apeli.fi>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.16-rc3

On Fri, Jun 20, 2025 at 04:25:58AM +0300, Jani Partanen wrote:
> 
> On 20/06/2025 4.09, Kent Overstreet wrote:
> > I'm not seeing that _you_ get that.
> 
> 
> How hard it is?
> 
> New feature window for 6.16 was 2 weeks ago.
> 
> rc<insert number here> is purely for fixing bugs, not adding new features
> and potential new bugs.

That's an easy rule for the rest of the kernel, where all your mistakes
are erased at a reboot. Filesystems don't have that luxury.

In the past, I've had to rush entire new on disk format features in
response to issues I saw starting to arise - I think more than once, but
the btree bitmap in the member info section was the big one that sticks
in my mind; that one was very hectic, but 100% proved its worth.

Thankfully, we're well past that. This time, we're just talking about a
~70 line patch that just picks overwrites instead of updates from the
journal and sorts them in reverse order.

So your next question might be - why not leave that in a branch for the
users that need it until the next merge window?

For a lot of users, compiling a kernel from some random git repository
is a lot to ask. I spend a lot of time doing what amounts to support;
that's just how it is these days. But rc kernels are packaged by most
kernels, and we absolutely do not want to wait an additional 3 months
for it to show up in a release kernel -

For something that might be the difference between losing a filesystem
and getting it back.

There's also a couple patches for tracepoints and introspection
improvements; I don't know if Linus was referring to those. But those
are important too.

I think at least as much about "how do I make this codebase easy to
debug; how do I make it _practical_ to support and QA when it's running
on random user machines in the wild" as I do about the debugging itself.
That's at least as important as the debugging; making it maintainable.

Partly that's about maintaining a quick feedback cycle between myself
and the users reporting issues; that builds trust, brings people into
the community, turns into opportunities to teach them more about testing
and QA and bug reporting.

I also never cease to be amazed how often I add some bit of logging or
improve a tracepoint or some introspection - and then a week later I'm
working on something else and it's exactly the thing I need.

IOW - it's not just about fixing the bugs, it's about how we fix the
bugs.

Tools to repair, tools to debug, it's all just tools, all the way
down...