linux-kernel - Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`

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: <ZC3cxzpnrnXf/osU@wedsonaf-dev>
Date:   Wed, 5 Apr 2023 17:40:39 -0300
From:   Wedson Almeida Filho <wedsonaf@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        rust-for-linux@...r.kernel.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>,
        linux-kernel@...r.kernel.org,
        Wedson Almeida Filho <walmeida@...rosoft.com>,
        Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
        Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`

On Wed, Apr 05, 2023 at 10:29:32PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 05, 2023 at 05:21:44PM -0300, Wedson Almeida Filho wrote:
> > On Wed, Apr 05, 2023 at 09:18:26PM +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 05, 2023 at 08:04:22PM +0200, Greg KH wrote:
> > > > On Wed, Apr 05, 2023 at 08:03:11PM +0200, Greg KH wrote:
> > > > > On Wed, Apr 05, 2023 at 02:51:01PM -0300, Wedson Almeida Filho wrote:
> > > > > > +void rust_helper_mutex_lock(struct mutex *lock)
> > > > > > +{
> > > > > > +	mutex_lock(lock);
> > > > > > +}
> > > > > > +EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
> > > > > > +
> > > > > 
> > > > > No need to ever unlock a mutex?
> > > > 
> > > > Oh nevermind, mutex_lock() is a macro, mutex_unlock() is not...
> > > 
> > > Yeah, so I despise all these stupid helpers... but I suppose it's the
> > > best they could come up with to interface the languages :/
> > > 
> > > The only hope is that the thing can do cross-language LTO or something
> > > to re-inline stuff.
> > 
> > One thing we could to do improve the situation is to convert some of the
> > existing macros into inline functions on the header files.
> > 
> > We can't do it for all cases (e.g., cases like mutex_init that declare a new
> > static variable when lockdep is enabled) but mutex_lock is just a function
> > when lockdep is disabled, and just calls mutex_lock_nested() when it is enabled.
> > 
> > How do you feel about this?
> > 
> > -#define mutex_lock(lock) mutex_lock_nested(lock, 0)
> > +static inline void mutex_lock(struct mutex *lock)
> > +{
> > +       mutex_lock_nested(lock, 0);
> > +}
> 
> Can rust actually parse C headers and inline C functions ? I thought the
> whole problem was that it can only call C ABI symbols (which inline
> functions are not).

Rust can't. We use a tool called bindgen to read C header files and generate
equivalent Rust (extern "C") declarations for functions. The tool has been
enhanced recently (https://github.com/rust-lang/rust-bindgen/pull/2335) to
handle static inline functions by automatically generating helpers like the one
above (in addition to the Rust decls).

So the situation is improved in that we don't need to manually write (and
commit) the helpers. It may improve further in the future if we get better
integration of the languages.