linux-kernel - Re: [PATCH 1/3] rust: block: introduce `kernel::block::mq` module

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: Mon, 13 May 2024 06:22:31 -0600
From: Bart Van Assche <bvanassche@....org>
To: Andreas Hindborg <nmi@...aspace.dk>, Jens Axboe <axboe@...nel.dk>,
 Christoph Hellwig <hch@....de>, Keith Busch <kbusch@...nel.org>,
 Damien Le Moal <Damien.LeMoal@....com>, Hannes Reinecke <hare@...e.de>,
 Ming Lei <ming.lei@...hat.com>,
 "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>
Cc: Andreas Hindborg <a.hindborg@...sung.com>,
 Wedson Almeida Filho <wedsonaf@...il.com>,
 Greg KH <gregkh@...uxfoundation.org>, Matthew Wilcox <willy@...radead.org>,
 Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <benno.lossin@...ton.me>, Alice Ryhl <aliceryhl@...gle.com>,
 Chaitanya Kulkarni <chaitanyak@...dia.com>,
 Luis Chamberlain <mcgrof@...nel.org>, Yexuan Yang <1182282462@...t.edu.cn>,
 Sergio González Collado <sergio.collado@...il.com>,
 Joel Granados <j.granados@...sung.com>,
 "Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>,
 Daniel Gomez <da.gomez@...sung.com>, Niklas Cassel <Niklas.Cassel@....com>,
 Philipp Stanner <pstanner@...hat.com>, Conor Dooley <conor@...nel.org>,
 Johannes Thumshirn <Johannes.Thumshirn@....com>,
 Matias Bjørling <m@...rling.me>,
 open list <linux-kernel@...r.kernel.org>,
 "rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
 "lsf-pc@...ts.linux-foundation.org" <lsf-pc@...ts.linux-foundation.org>,
 "gost.dev@...sung.com" <gost.dev@...sung.com>
Subject: Re: [PATCH 1/3] rust: block: introduce `kernel::block::mq` module

On 5/12/24 11:39, Andreas Hindborg wrote:
> +    /// Set the logical block size of the device.
> +    ///
> +    /// This is the smallest unit the storage device can address. It is
> +    /// typically 512 bytes.

Hmm ... all block devices that I have encountered recently have a
logical block size of 4096 bytes. Isn't this the preferred logical
block size for SSDs and for SMR hard disks?

> +    /// Set the physical block size of the device.
> +    ///
> +    /// This is the smallest unit a physical storage device can write
> +    /// atomically. It is usually the same as the logical block size but may be
> +    /// bigger. One example is SATA drives with 4KB sectors that expose a
> +    /// 512-byte logical block size to the operating system.

Please be consistent and change "4 KB sectors" into "4 KB physical block
size".

I think that the physical block size can also be smaller than the
logical block size. From the SCSI SBC standard:

Table 91 — LOGICAL BLOCKS PER PHYSICAL BLOCK EXPONENT field
-----  ------------------------------------------------------------
Code   Description
-----  ------------------------------------------------------------
0      One or more physical blocks per logical block (the number of
        physical blocks per logical block is not reported).
n > 0  2**n logical blocks per physical block
-----  ------------------------------------------------------------

> +impl<T: Operations, S: GenDiskState> GenDisk<T, S> {
> +    /// Call to tell the block layer the capacity of the device in sectors (512B).

Why to use any other unit than bytes in Rust block::mq APIs? sector_t
was introduced before 64-bit CPUs became available to reduce the number
of bytes required to represent offsets. I don't think that this is still
a concern today. Hence my proposal to be consistent in the Rust 
block::mq API and to use bytes as the unit in all APIs.

Thanks,

Bart.