linux-kernel - Re: [PATCH v2 1/1] rust: refactor to_result to return the original value

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250910075018.706163e2@nimda.home>
Date: Wed, 10 Sep 2025 07:50:18 +0300
From: Onur Özkan <work@...rozkan.dev>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
 daniel@...lak.dev, dirk.behme@...bosch.com, felipe_life@...e.com,
 tamird@...il.com, dakr@...nel.org, tmgross@...ch.edu, aliceryhl@...gle.com,
 a.hindborg@...nel.org, lossin@...nel.org, bjorn3_gh@...tonmail.com,
 gary@...yguo.net, boqun.feng@...il.com, alex.gaynor@...il.com,
 ojeda@...nel.org
Subject: Re: [PATCH v2 1/1] rust: refactor to_result to return the original
 value

On Tue, 9 Sep 2025 22:05:53 +0200
Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote:

> On Tue, Sep 9, 2025 at 7:43 PM Onur Özkan <work@...rozkan.dev> wrote:
> >
> > That change was incompatible with v1 (due to the different
> > signature of to_result), which fails to build with my patch. This
> > version (v2) fixes the issue introduced in v1.
> 
> In that case, please try to avoid mentioning "broken" or "fix" or
> similar, i.e. there is nothing broken in the tree itself (the commit
> message should mention what is done in the patch). If you want to give
> extra clarifications, then you can always add them outside the commit
> message, below the `---` line.
> 
> In addition, if the changes here are required to be done all at once,
> then please do not rebase on top of regulator -- this would need to go
> into the global Rust tree. Otherwise, any changes that does not need
> to go at the same time should go separately so that it is easier to
> land.
> 
> Finally, I am not sure I follow the `unwrap_or(0)` here. If one passes
> a negative enough `i64`, wouldn't that mean `Ok` starts to be
> returned? Currently all negatives that are not codes are supposed to
> be bugs.
> 

I think the best approach would be to return `EINVAL` from `to_result`,
what do yo think?

> Either way, I think this should probably go on top of
> https://lore.kernel.org/rust-for-linux/20250829192243.678079-3-ojeda@kernel.org/,
> since that adds documentation, and thus it would be nice to adjust
> that one to whatever the generic one should do now, especially if the
> semantics are changing.
> 
> Thanks!
> 
> Cheers,
> Miguel

I will do that in v3.

Thanks,
Onur