linux-kernel - Re: [PATCH v2 1/8] rust: fs: add file::Offset type alias

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: <DDO6IUEAVBR0.14AZ0UXFYQF48@kernel.org>
Date: Tue, 21 Oct 2025 19:34:12 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>
Cc: <gregkh@...uxfoundation.org>, <rafael@...nel.org>, <ojeda@...nel.org>,
 <alex.gaynor@...il.com>, <boqun.feng@...il.com>, <gary@...yguo.net>,
 <bjorn3_gh@...tonmail.com>, <lossin@...nel.org>, <a.hindborg@...nel.org>,
 <aliceryhl@...gle.com>, <tmgross@...ch.edu>, <mmaurer@...gle.com>,
 <rust-for-linux@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, "Alexander Viro" <viro@...iv.linux.org.uk>,
 "Christian Brauner" <brauner@...nel.org>, "Jan Kara" <jack@...e.cz>
Subject: Re: [PATCH v2 1/8] rust: fs: add file::Offset type alias

On Tue Oct 21, 2025 at 6:47 PM CEST, Miguel Ojeda wrote:
> If it is just e.g. add/sub and a few from/into, then it sounds ideal
> (i.e. I am worried if it wants to be used as essentially a primitive,
> in which case I agree it would need to be automated to some degree).

That's what I need for this patch series, I think the operations applicable for
this type are quite some more; not that far from a primitive.

> To me, part of that is restricting what can be done with the type to
> prevent mistakes.
>
> i.e. a type alias is essentially the wild west, and this kind of
> type/concept is common enough that it sounds a good idea to pay the
> price to provide a proper type for it.

The reason why I said for this case I think it would be good to have derive
macros first is that there's a lot of things that are valid to do with an offset
value.

Of course, there's also a lot of things that don't make a lot of sense that we
could prevent (e.g. reverse_bits(), ilogX(), etc.).

I think in this case there not a lot to gain from preventing this, considering
that we don't have derive macros yet.

However, I understand where you're coming from. Even though there's not a huge
gain here, it would be good to set an example -- especially if it's something as
cental as a file offset type.

If this is what you have in mind, let me go ahead and do it right away (at least
for the things needed by this patch series), because that's a very good reason I
think.

> So I don't want to delay real work, and as long as we do it early
> enough that we don't have many users, that sounds like a good idea to
> me -- done:
>
>     https://github.com/Rust-for-Linux/linux/issues/1198
>
> Also took the chance to ask for a couple examples/tests.

Thanks a lot for creating the issue!

(I mainly also thought of adding one for a derive macro.)