linux-kernel - Re: [PATCH 01/10] block: introduce BLK_FEAT_WRITE_ZEROES

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: <20250616053901.GA1533@lst.de>
Date: Mon, 16 Jun 2025 07:39:01 +0200
From: Christoph Hellwig <hch@....de>
To: Zhang Yi <yi.zhang@...weicloud.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>, Christoph Hellwig <hch@....de>,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
	linux-block@...r.kernel.org, dm-devel@...ts.linux.dev,
	linux-nvme@...ts.infradead.org, linux-scsi@...r.kernel.org,
	linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	tytso@....edu, john.g.garry@...cle.com, bmarzins@...hat.com,
	chaitanyak@...dia.com, shinichiro.kawasaki@....com,
	brauner@...nel.org, martin.petersen@...cle.com, yi.zhang@...wei.com,
	chengzhihao1@...wei.com, yukuai3@...wei.com, yangerkun@...wei.com
Subject: Re: [PATCH 01/10] block: introduce BLK_FEAT_WRITE_ZEROES_UNMAP to
 queue limits features

On Sat, Jun 14, 2025 at 12:48:26PM +0800, Zhang Yi wrote:
> >> Maybe we should redo this similar to the other hardware/software interfaces
> >> and have a hw_ limit that is exposed by the driver and re-only in
> >> sysfs, and then the user configurable one without _hw.  Setting it to
> >> zero disables the feature.
> > 
> > Yeah, that fits the /sys/block/foo/queue model better.
> > 
> 
> OK, well. Please let me confirm, are you both suggesting adding
> max_hw_write_zeores_unmap_sectors and max_write_zeroes_unmap_sectors to
> the queue_limits instead of adding BLK_FEAT_WRITE_ZEROES_UNMAP to the
> queue_limits->features. Something like the following.

Yes.

> Besides, we should also rename max_write_zeroes_sectors to
> max_hw_write_zeroes_sectors since it is a hardware limitation reported
> by the driver.  If the device supports unmap write zeroes,
> max_hw_write_zeores_unmap_sectors should be equal to
> max_hw_write_zeroes_sectors, otherwise it should be 0.

We've only done the hw names when we allow and overwrite or cap based
on other values.  So far we've not done any of that to
max_write_zeroes_sectors.