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: <20230906000007.ry5rmk35vt57kppx@moria.home.lan>
Date:   Tue, 5 Sep 2023 20:00:07 -0400
From:   Kent Overstreet <kent.overstreet@...ux.dev>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-bcachefs@...r.kernel.org,
        Christian Brauner <christian@...uner.io>
Subject: Re: [GIT PULL] bcachefs

On Tue, Sep 05, 2023 at 06:24:47AM -0700, Christoph Hellwig wrote:
> Hi Kent,
> 
> I thought you'd follow Christians proposal to actually work with
> people to try to use common APIs (i.e. to use iomap once it's been
> even more iter-like, for which I'm still waiting for suggestions),
> and make your new APIs used more widely if they are a good idea
> (which also requires explaining them better) and aim for 6.7 once
> that is done.

Christoph, I get that iomap is your pet project and you want to make it
better and see it more widely used.

But the reasons bcachefs doesn't use iomap have been discussed at
length, and I've posted and talked about the bcachefs equivalents of
that code. You were AWOL on those discussions; you consistently say
"bcachefs should use iomap" and then walk away, so those discussions
haven't moved forwards.

To recap, besides being more iterator like (passing data structures
around with iterators, vs. indirect function calls into the filesystem),
bcachefs also hangs a bit more state off the pagecache, due to being
multi device and also using the same data structure for tracking disk
reservations (because why make the buffered write paths look that up
separately?).

> But without that, and without being in linux-next and the VFS maintainer
> ACK required for I think this is a very bad idea.

Christain gave his reviewed-by for the dcache patch. Since this patchset
doesn't change existing code maintained by others aside from that one
patch, not sure how linux-next is relevant here...