linux-kernel - Re: [GIT PULL] SCSI postmerge updates for the 6.8+ merge window

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]

Date: Fri, 22 Mar 2024 16:24:17 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-scsi
	 <linux-scsi@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] SCSI postmerge updates for the 6.8+ merge window

On Fri, 2024-03-22 at 12:55 -0700, Linus Torvalds wrote:
> On Fri, 22 Mar 2024 at 12:12, James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> > 
> > Eleven patches that are based on the rw_hint branch of the vfs tree
> > which contained the base block and fs changes needed to support
> > this. 8 patches are in the debug driver and 3 in the core.
> 
> Please people - the number of patches involved is entirely
> immaterial.
> 
> I want my merge messages to say what those patches *do*?
> 
> This whole "how many patches" thing is a disease. It's not even
> remotely interesting. I see the size of the patch in the diffstat,
> and that actually has some meaning in the sense of "how much does
> this pull actually change", whether it's in one patch or a hundred.
> 
> I have absolutely *zero* idea what the above pull request actually
> asks me to pull.
> 
> So I won't.

OK, try this (I've updated the scsi-misc tag with it as well)

The vfs has long had a write lifetime hint mechanism that gives the
expected longevity on storage of the data being written.  f2fs was the
original consumer of this and used the hint for flash data placement
(mostly to avoid write amplification by placing objects with similar
lifetimes in the same erase block).  More recently the SCSI based UFS
(Universal Flash Storage) drivers have wanted to take advantage of this
as well, for the same reasons as f2fs, necessitating plumbing the write
hints through the block layer and then adding it to the SCSI core.  The
vfs write_hints pull you've already taken plumbs this as far as block
and this pull request completes the SCSI core enabling based on a
recently agreed reuse of the old write command group number.  The
additions to the scsi_debug driver are for emulating this property so
we can run tests on it in the absence of an actual UFS device.

James