linux-kernel - Re: [PATCH] rcu: do not include rtmutex

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] [day] [month] [year] [list]

Date:   Thu, 19 Oct 2017 12:50:49 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     kbuild test robot <fengguang.wu@...el.com>, kbuild-all@...org,
        Josh Triplett <josh@...htriplett.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rcu: do not include rtmutex_common.h unconditionally

On Thu, Oct 19, 2017 at 08:15:05PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-10-18 13:42:59 [-0700], Paul E. McKenney wrote:
> > 
> > Builds for me on x86 and 0day test robot hasn't complained, but might
> > as well get it right.
> 
> So I checked you tree and there is this:
> 
> |$ git one bc2eecd7ecce40af43b6eb3d256b6076257df846
> |bc2eecd7ecce ("futex: Allow for compiling out PI support")
> |$ git describe bc2eecd7ecce40af43b6eb3d256b6076257df846 --contains
> |v4.14-rc1~162^2~57
> 
> so this exploded on my side because I applied it on top of v3.13, you on
> the other hand had it post v4.13-rc1 so it was all good.
> Now, that it is possible to include that header file with and without
> CONFIG_RT_MUTEX=y we could indeed move that include outside of that
> ifdef. Sorry for that.

Sounds like something I would do!  ;-)

> We could do that and move the two defines (rt_mutex_owner +
> rt_mutex_futex_unlock) to the rtmutex_common.h like in bc2eecd7ecce.
> This might look good, I don't know. If you want, I can prepare a patch
> for that, we could leave it as it…

One advantage is that builds would go more easily, and things like
RCU that need to build either way wouldn't need their own splat-generating
definitions of the rt_mutex primitives.

On the other hand, this would lose the current build-time detection
of use of rt_mutux on architectures not providing it.

Given the choice, I would prefer the build-time detection.

Thoughts?

							Thanx, Paul

> >                        The new commits are:
> > 
> > a06f537e75ea ("rcu: do not include rtmutex_common.h unconditionally")
> > 4a0fb5d70bb2 ("rcu: Suppress lockdep false-positive ->boost_mtx complaints")
> 
> Okay, thanks.
> 
> > 							Thanx, Paul
> 
> Sebastian
>