linux-kernel - Re: [GIT PULL] block-bio_iov_iter

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: <wrcaluw3pxx65tgznv5z3td3xb2tdf6rwucze5sy7bqrutj4jp@srde54eo3iyz>
Date: Mon, 20 Oct 2025 10:49:57 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Christoph Hellwig <hch@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	linux-kernel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-block@...r.kernel.org
Subject: Re: [GIT PULL] block-bio_iov_iter_export

On Mon, Oct 20, 2025 at 06:21:36AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 20, 2025 at 08:56:59AM -0400, Kent Overstreet wrote:
> > The implementation has morphed given multipage bvecs and iov_iters, but
> > otherwise it looks structurally much the same as the version I
> > originally introduced.
> 
> Not a pissing context, but I introduced it.  I attributed the git
> authorship you because it fundamentally it based on your idea but with a
> lot of tweaks.  I and many others do this to give proper credit.

Christoph, I don't know what you're claiming here. I see no tweaks in
the original patch, that's all code I wrote.

> > Please attribute correctly, and that would've included CCing me on the
> > patch that dropped the EXPORT_SYMBOL().
> 
> No, we don't Cc the author of each line of code or even function.  The
> relevant maintainer here is Jens.

I always try to CC people with relevant expertise, and that _definitely_
includes the person who authored the code being changed.

And considering the multiple times I've had to track down bugs you and
Jens introduced into code I wrote without CCing me...

> > The way you're doing it with bdev_logical_block_size() is just wrong -
> > even for single device filesystems! - because it's the filesystem
> > blocksize that's relevant here and that isn't necessarily going to match
> > (even if it matched when the filesystem was formatted, filesystems can
> > be moved to different block devices).
> 
> I'm not sure what you are talking about, but the changes you seem to
> be complaining about are making the alignment boundary a caller provided
> argument.  Which seems to be what you're arguing for here?

You brought up the bdev NULL check.

> Either way this is the wrong venue.  If you want to change something
> sent patches following the usual guidelines to the maintainer.

There was no need for you to drop the EXPORT_SYMBOL.

What I want to know is, is this going to become a pattern?

I can vendorize this one function, but If you're going to make a habit
of ripping out exports and functionality bcachefs depends on, I can't
expect I'll always be able to. There's open bug on the bcachefs bug
tracker for 6.18 support, and people are just patching the kernel to
deal with this. I'll just pass the bcachefs enablement patches to the
distros if it looks like that's going to be less of a hassle.

With the lib/Kconfig patch to make library code user selectable that you
also nacked, perhaps that's the safer route here.