On 7/16/25 2:26 AM, Keith Busch wrote: > On Mon, Jul 14, 2025 at 03:17:13PM +0200, Christoph Hellwig wrote: >> Is is just me, or would it be a good idea to require an explicit >> opt-in to user hardware atomics? > > IMO, if the block device's limits reports atomic capabilities, it's fair > game for any in kernel use. These are used outside of filesystems too, > like through raw block fops. > > We've already settled on discarding problematic nvme attributes from > consideration. Is there something beyond that you've really found? If > so, maybe we should continue down the path of splitting more queue > limits into "hardware" and "user" values, and make filesystems subscribe > to the udev value where it defaults to "unsupported" for untrusted > devices. > If we're going down the path of disregarding atomic write support for NVMe devices that don't report NAWUPF, then we likely need an opt-in mechanism for users who trust their device to have a sane AWUPF value. For example, consider an NVMe disk that does not support NAWUPF, but does consistently support AWUPF across all namespaces and for different LBA sizes. In such cases, I would still want to enable atomic writes on this disk, even if the kernel driver marks it as "unsupported" due to missing NAWUPF. Having an explicit user opt-in mechanism in such scenarios would be very useful, allowing advanced users to take advantage of hardware capabilities they trust, despite conservative kernel defaults. Thanks, --Nilay
