linux-kernel - Re: [GIT PULL] bcachefs

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: <2aeebe7c-c769-a258-a2b7-c96816f97dbe@meta.com>
Date:   Thu, 7 Sep 2023 10:29:45 -0400
From:   Chris Mason <clm@...a.com>
To:     Kees Cook <keescook@...omium.org>,
        Kent Overstreet <kent.overstreet@...ux.dev>
Cc:     Nathan Chancellor <nathan@...nel.org>,
        torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-bcachefs@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs

On 9/6/23 8:03 PM, Kees Cook wrote:
> On Wed, Sep 06, 2023 at 03:28:47PM -0700, Nathan Chancellor wrote:
>> Hi Kent,
>>
>> On Sat, Sep 02, 2023 at 11:25:55PM -0400, Kent Overstreet wrote:
>>> here's the bcachefs pull request, for 6.6. Hopefully everything
>>> outstanding from the previous PR thread has been resolved; the block
>>> layer prereqs are in now via Jens's tree and the dcache helper has a
>>> reviewed-by from Christain.
>>
>> I pulled this into mainline locally and did an LLVM build, which found
>> an immediate issue. It appears the bcachefs codes uses zero length
> 
> It looks like this series hasn't been in -next at all? That seems like a
> pretty important step.
> 
> Also, when I look at the PR, it seems to be a branch history going
> back _years_. For this kind of a feature, I'd expect a short series of
> "here's the code" in incremental additions (e.g. look at the x86 shstk
> series), not the development history from it being out of tree -- this
> could easily lead to ugly bisection problems, etc.

When we merged btrfs, Linus helped redo all of the btrfs out of tree
commits on top of kernel git.  I can't remember at this point if it was
his idea or mine, but git history is obviously improved by remembering
my sparse file joy:

commit 3a686375629da5d2e2ad019265b66ef113c87455
Author: Chris Mason <chris.mason@...cle.com>
Date:   Thu May 24 13:35:57 2007 -0400

    Btrfs: sparse files!

I'd have a preference for keeping the old history, warts and all, but
wanted to give a data point to help jog people's memory around problems
it might have caused.

-chris