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]
Message-Id: <20171019195049.GA3521@linux.vnet.ibm.com>
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
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ