linux-kernel - Re: [RFC 2/5] rust: sync: Arc: Introduces ArcInner::count()

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: <CANiq72kMZ9XQvte41Mzu4oXX=ujGRCrGDZDiYUBVD3=JTGG57g@mail.gmail.com>
Date:   Thu, 2 Feb 2023 22:47:12 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Boqun Feng <boqun.feng@...il.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>, Gary Guo <gary@...yguo.net>,
        Peter Zijlstra <peterz@...radead.org>,
        rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
        Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Miguel Ojeda <ojeda@...nel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...il.com>,
        Björn Roy Baron <bjorn3_gh@...tonmail.com>,
        Vincenzo Palazzo <vincenzopalazzodev@...il.com>
Subject: Re: [RFC 2/5] rust: sync: Arc: Introduces ArcInner::count()

On Thu, Feb 2, 2023 at 5:52 PM Boqun Feng <boqun.feng@...il.com> wrote:
>
> As I said, I'm open to remove the printing of the refcount, and if you
> and Peter think maybe it's OK to do that after the explanation above,

Perhaps part of the confusion came from the overloaded "safe" term.

When Gary and Boqun used the term "safe", they meant it in the Rust
sense, i.e. calling the method will not allow to introduce undefined
behavior. While I think Peter and Greg are using the term to mean
something different.

In particular, "safe" in Rust does not mean "hard to misuse" or "OK to
use in production" or "avoids functional bugs" or "prevents crashes"
and so on. And, yeah, this is a common source of misunderstandings,
and some argue a better term could have been chosen.

So it is possible to have perfectly safe Rust functions that are very
tricky to use or unintended for common usage. Now, of course, whether
having a particular function is a good idea or not is a different
story.

Boqun: maybe appending a small paragraph to the doc comments of the
function would alleviate concerns.

Cheers,
Miguel