linux-kernel - Re: [RFC PATCH] nvme: add an opt-in to use AWUPF

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: <14bfcc0e-ec43-4876-9b45-1f2824e1b059@oracle.com>
Date: Thu, 21 Aug 2025 11:33:25 +0100
From: John Garry <john.g.garry@...cle.com>
To: Christoph Hellwig <hch@....de>
Cc: kbusch@...nel.org, axboe@...nel.dk, sagi@...mberg.me,
        linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org,
        tytso@....edu, nilay@...ux.ibm.com, martin.petersen@...cle.com,
        djwong@...nel.org, mcgrof@...radead.org
Subject: Re: [RFC PATCH] nvme: add an opt-in to use AWUPF

On 21/08/2025 09:35, Christoph Hellwig wrote:
>> +	list_for_each_entry(tmp, &subsys->ctrls, subsys_entry)
>> +		nvme_queue_scan(tmp);
> queueing a full rescan here seems expensive.  What about just keeping
> the awupf value in our internal data structures and always use it
> for the physical block size calculation,

is that even ok? physical block size implies atomicity also.

> but only apply it to the
> atomic limits based on a flag?

We have flag BLK_FEAT_ATOMIC_WRITES, which could be used, but in 
blk_validate_atomic_write_limits() we zero the hw limits if that flag is 
unset. So we need to fill in the hw limits like in this patch.