linux-kernel - Re: [PATCH 0/7] block layer patches for 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] [day] [month] [year] [list]

Message-ID: <ZH5TFBy5j1eUxg00@moria.home.lan>
Date:   Mon, 5 Jun 2023 17:26:44 -0400
From:   Kent Overstreet <kent.overstreet@...ux.dev>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/7] block layer patches for bcachefs

On Mon, Jun 05, 2023 at 10:49:37AM -0600, Jens Axboe wrote:
> On 6/4/23 5:38?PM, Kent Overstreet wrote:
> > On Tue, May 30, 2023 at 10:50:55AM -0600, Jens Axboe wrote:
> >> Sorry typo, I meant text. Just checked stack and it looks identical, but
> >> things like blk-map grows ~6% more text, and bio ~3%. Didn't check all
> >> of them, but at least those two are consistent across x86-64 and
> >> aarch64. Ditto on the data front. Need to take a closer look at where
> >> exactly that is coming from, and what that looks like.
> > 
> > A good chunk of that is because I added warnings and assertions for
> > e.g. running past the end of the bvec array. These bugs are rare and
> > shouldn't happen with normal iterator usage (e.g. the bio_for_each_*
> > macros), but I'd like to keep them as a debug mode thing.
> > 
> > But we don't yet have CONFIG_BLOCK_DEBUG - perhaps we should.
> 
> Let's split those out then, especially as we don't have a BLOCK_DEBUG
> option right now.

Already did that; there's a patch in the branch that adds
CONFIG_BLK_DEBUG with the new assertions.

> Cn you resend just the iterator changes in their current form? The
> various re-exports are a separate discussion, I think we should focus on
> the iterator bits first.

They're up in that branch with the iterator changes first now; I'll mail
them out too.