linux-kernel - Re: [PATCH] cgroup/cpuset: fix circular locking dependency

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

Message-Id: <20180110200821.GA22541@linux.vnet.ibm.com>
Date:   Wed, 10 Jan 2018 12:08:21 -0800
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     Prateek Sood <prsood@...eaurora.org>,
        Peter Zijlstra <peterz@...radead.org>, avagin@...il.com,
        mingo@...nel.org, linux-kernel@...r.kernel.org,
        cgroups@...r.kernel.org, sramana@...eaurora.org
Subject: Re: [PATCH] cgroup/cpuset: fix circular locking dependency

On Tue, Jan 09, 2018 at 08:00:22AM -0800, Paul E. McKenney wrote:
> On Tue, Jan 09, 2018 at 07:37:52AM -0800, Tejun Heo wrote:
> > Hello, Paul.
> > 
> > On Tue, Jan 09, 2018 at 07:21:12AM -0800, Paul E. McKenney wrote:
> > > > The code was previously using both system_power_efficient_wq and
> > > > system_workqueue (for the expedited path).  I guess the options were
> > > > either using two workqueues or dropping POWER_EFFICIENT.  I have no
> > > > idea how big an impact this will make or whether it'd even be
> > > > noticeable but maybe it'd be worthwhile to mention that in the
> > > > description?
> > > 
> > > Good point!  How about if I change the last paragraph of the commit
> > > log to read as follows?
> > > 
> > > 							Thanx, Paul
> > > 
> > > ------------------------------------------------------------------------
> > > 
> > > This commit also causes SRCU to use this new RCU-specific
> > > workqueue_struct.  Note that SRCU's use of workqueues never blocks them
> > > waiting for readers, so this should be safe from a forward-progress
> > > viewpoint.  Note that this moves SRCU from system_power_efficient_wq
> > > to a normal workqueue.  In the unlikely event that this results in 
> > > measurable degradation, a separate power-efficient workqueue will be
> > > creates for SRCU.
> > 
> > Sounds good.  Please feel free to add
> > 
> >  Acked-by: Tejun Heo <tj@...nel.org>
> 
> Done, thank you!

And one additional question...  How are we pushing this upstream?  By
default, I would push things starting this late into the merge window
following the next one (v4.17), but would be more than willing to make
an exception given that this fixes a valid real-world complaint.

For that matter, if you would rather push my commit along with your pair
of commits, that works for me!  Either way, please just let me know.

							Thanx, Paul