linux-kernel - Re: [PATCH v2] nvmet: Make blksize

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: <3078386.UTt5R2Mg1o@nailgun>
Date: Tue, 01 Jul 2025 17:00:06 +0200
From: Richard Weinberger <richard@...ma-star.at>
To: Richard Weinberger <richard@....at>, linux-nvme@...ts.infradead.org,
 upstream@...ma-star.at, Damien Le Moal <dlemoal@...nel.org>
Cc: linux-kernel@...r.kernel.org, kch@...dia.com, sagi@...mberg.me,
 hch@....de, upstream+nvme@...ma-star.at
Subject: Re: [PATCH v2] nvmet: Make blksize_shift configurable

On Dienstag, 1. Juli 2025 09:32 Damien Le Moal wrote:
> > The initial intention of this patch was exposing the blksize_shift property.
> > If we want to expose this as more user friendly, I'm fine with it.
> > Maybe "minimum_io_size"?
> 
> That likely will be confusing with the existing device limit io_min. I think
> block_size is clear.

Ok!

> > 
> >> Also, if the backend is an HDD, do we want to allow the user to configure a
> >> block size that is less than the *physical* block size ? Performance will
> >> suffer on regular HDDs and writes may fail with SMR HDDs.
> > 
> > I'm not sure whether it's worth putting more smartness into this logic.
> 
> This may be nice to avoid users shooting themselves in the foot with a bad
> setup and us having to deal with bad performance complaints...
> If we do not do anything special, we will be stuck with it as a more
> restrictive setup later may break some (bad) user setups. That is why I raised
> the point :)

Detecting whether the backend is an HDD should work via bdev_nonrot().
So, we could issue a warning if bdev_nonrot() is true and the configured
block size is less than bdev_physical_block_size()?

> >> I am confused... This is going to check both... But if you got STATX_DIOALIGN
> >> and it is OK, you do not need (and probably should not) do the second if, no ?
> > 
> > I was not sure about that.
> > Is it guaranteed that STATX_DIOALIGN returns something sane?
> 
> If it is defined by the FS, yes. But it may not be defined, so in that case,
> you have to use the fallback of the bdev block size.

Ok!

LG,
//richard

-- 
sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y