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

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: <a448243d-8ef8-48d8-afbc-2c45068c882c@tnxip.de>
Date: Wed, 2 Jul 2025 20:49:32 +0200
From: Malte Schröder <malte.schroeder@...ip.de>
To: Kent Overstreet <kent.overstreet@...ux.dev>,
 "Carl E. Thompson" <cet@...lthompson.net>
Cc: John Stoffel <john@...ffel.org>,
 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-rc4

On 02.07.25 19:53, Kent Overstreet wrote:
> On Wed, Jul 02, 2025 at 10:41:34AM -0700, Carl E. Thompson wrote:
>> Kent, at this point in bcachefs' development you want complete control
>> over your development processes and timetable that you simply can't
>> get in the mainline kernel. It's in your own best interest for you to
>> develop out-of-tree for now.
> Carl, all I'm doing is stating up front what it's going to take to get
> this done right.
>
> I'm not particularly pushing one way or the other for bcachefs to stay
> in; there are pros and cons either way. It'll be disruptive for it to be
> out, but if the alternative is disrupting process too much and driving
> Linus and I completely completely nuts, that's ok.
>
> Everyone please be patient. This is a 10+ year process, no one thing is
> make or break.
>
So as a user usually hanging out on IRC and running Kent's trees:

I think most of those people actually testing bcachefs are either
running bcachefs-master, -rc or some outdated distro kernel. From my
perspective I'd think it would be good enough to push for-upstream
during the merge window and then only provide further patches if there
where regressions or some really bad bug appears that actually eats data
(like the one that bit me). If it's "just" stability fixes, well, if
people running a distro kernel hit those bugs they'll need to build a
-rc kernel anyways to get fixes, those could just build bcachefs-master.
When running Linus' tree I am aware and accept that I am not running the
absolutely latest code.

I've had some pretty bad experience with amdgpu requiring out of tree
patches to get my system running free of glitches, which took months to
get into upstream. It's annoying, but I accept that.

I'd rather have a slightly outdated bcachefs in kernel than not at all.
It is good to have a distro kernel I can fall back to if I mess up my
own kernel building ;)

my 0.02€

/Malte