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...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ