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]

Date:   Wed, 5 Apr 2023 17:21:44 -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 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);
+}
+