linux-kernel - Re: Is it really safe to use workqueues to drive expedited grace periods?

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

Message-Id: <20170304001715.GA30506@linux.vnet.ibm.com>
Date:   Fri, 3 Mar 2017 16:17:15 -0800
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     jiangshanlai@...il.com, linux-kernel@...r.kernel.org
Subject: Re: Is it really safe to use workqueues to drive expedited grace
 periods?

On Fri, Mar 03, 2017 at 11:30:49AM -0800, Tejun Heo wrote:
> Hello, Paul.
> 
> Sorry about the long delay.  Travel + sickness.  Just starting to
> catch up with things now.

No problem, I have been distracted by other projects in any case.  ;-)

> On Mon, Feb 13, 2017 at 04:16:00PM -0800, Paul E. McKenney wrote:
> > Thank you for the information!  So if I am to continue using workqueues
> > for expedited RCU grace periods, I believe that need to do the following:
> > 
> > 1.	Use alloc_workqueue() to create my own WQ_MEM_RECLAIM
> > 	workqueue.
> 
> This is only necessary if RCU can be in a dependency chain in the
> memory reclaim path - e.g. somebody doing synchronize_expedited_rcu()
> in some obscure writeback path; however, given how wildly RCU is used,
> I don't think this is a bad idea.  The only extra overhead which comes
> from it is memory used for an extra workqueue and a rescuer thread
> after all.

I suspect that SLAB_DESTROY_BY_RCU qualifies -- such a slab allocator
could have a great many slabs waiting for an RCU grace period.

> > 2.	Rework my workqueue handler to avoid blocking waiting for
> > 	the expedited grace period to complete.  I should be able
> > 	to do a small number of timed wait, but if I actually
> > 	wait for the grace period to complete, I might end up
> > 	hogging the reserved items.  (Or does my workqueue supply
> > 	them for me?  If so, so much the better!)
> 
> So, what the dedicated workqueue w/ WQ_MEMRECLAIM guarantees is that
> there will always be at least one worker thread which is executing
> work items from the workqueue.
> 
> As long as your workqueue usage guarantees forward progress - that is,
> as long as one work item in the workqueue won't block indefinitely on
> another work item on the same workqueue, you shouldn't need to reword
> the workqueue handler.
> 
> If there can be dependency chain among work items of the same
> WQ_MEMRECLAIM workqueue, often the best approach is breaking up the
> chain and putting them into their own WQ_MEMRECLAIM workqueues.

Thank you, good to know!

> > 3.	Concurrency would not be a problem -- there can be no more
> > 	four work elements in flight across both possible flavors
> > 	of expedited grace periods.
> 
> You usually don't have to worry about concurrency all that much with
> workqueues.  They'll provide the maximum the system can as long as
> that's possible.
> 
> If the four work items can depend on each other, it'd be best to put
> them in separate workqueues.  If not, there's nothing to worry about.

For a given pair, one can be acquiring a mutext that the other holds.
Ah, so if only one task was running, that would fail to make forward
progress.  That said, splitting would be a bit weird in this case,
because alternating grace periods for a given RCU flavor would need
to schedule work on a different workqueue.  Might be easier to do
mutex_trylock() and reschedule...

And thank you for the info, very helpful!

							Thanx, Paul