linux-kernel - Re: [GIT PULL] bcachefs fixes for 6.12-rc2

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: <v2k6atl7hlaxw4ktu4e2j7mj67sbz63vzrqk6pnxmntrkuzwut@3k4knhrlnqeb>
Date: Sun, 6 Oct 2024 13:18:00 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Martin Steigerwald <martin@...htvoll.de>
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.12-rc2

On Sun, Oct 06, 2024 at 01:49:23PM GMT, Martin Steigerwald wrote:
> Hi Kent, hi Linus.
> 
> Kent Overstreet - 06.10.24, 02:54:32 CEST:
> > On Sat, Oct 05, 2024 at 05:14:31PM GMT, Linus Torvalds wrote:
> > > On Sat, 5 Oct 2024 at 16:41, Kent Overstreet 
> <kent.overstreet@...ux.dev> wrote:
> > > > If what you want is patches appearing on the list, I'm not unwilling
> > > > to
> > > > make that change.
> > > 
> > > I want you to WORK WITH OTHERS. Including me - which means working
> > > with the rules and processes we have in place.
> > 
> > That has to work both ways.
> 
> Exactly, Kent.
> 
> And it is my impression from reading the whole thread up to now and from 
> reading previous threads it is actually about: Having your way and your 
> way only.
> 
> That is not exactly "work both ways".
> 
> Quite similarly regarding your stand towards distributions like Debian.

My issue wasn't with Debian as a whole; it was with one particular
packaging rule which was causing issues, and a maintainer who - despite
warnings that it would cause issues - broke the build and sat on it,
leaving a broken version up, which resulted in users unable to access
their filesystems when they couldn't mount in degraded mode.

> I still do have a BCacheFS on my laptop for testing, but meanwhile I 
> wonder whether some of the crazy kernel regressions I have seen with the 
> last few kernels where exactly related to having mounted that BCacheFS 
> test filesystem. I am tempted to replace the BCacheFS with a BTRFS just to 
> find out.

I think you should be looking elsewhere - there have been zero reports
of random crashes or anything like what you're describing. Even in
syzbot testing we've been pretty free from the kind of memory safety
issues that would cause random crashes

The closest bugs to what you're describing would be the
__wait_on_freeing_inode() deadlock in 6.12-rc1, and the LZ4HC crash that
I've yet to triage - but you specifically have to be using lz4:15
compression to hit that path.

The worst syzbot has come up with is something strange at the boundary
with the crypto code, and I haven't seen any user reports that line up
with that one.