linux-kernel - Re: [PATCH 3/7] wait.[ch]: Introduce the simple waitqueue (swait) implementation

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:	Mon, 20 Oct 2014 12:05:42 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Peter Zijlstra <peterz@...radead.org>,
	<linux-rt-users@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH 3/7] wait.[ch]: Introduce the simple waitqueue (swait)
 implementation

[Re: [PATCH 3/7] wait.[ch]: Introduce the simple waitqueue (swait) implementation] On 20/10/2014 (Mon 11:40) Steven Rostedt wrote:

> On Mon, 20 Oct 2014 11:21:44 -0400
> Paul Gortmaker <paul.gortmaker@...driver.com> wrote:
> 
> > > Right, and we should slap Paul for not showing up for it ;-)
> > 
> > And miss turkey day?  ;-)
> 
> Replace it with Alt Beer day!
> 
> 
> > I'd like to hear more details on what you had in mind here, so I don't
> > go chasing down the wrong road.  So the local list head gets all the
> > items (via list_cut or moves?) and then that local list is spliced onto
> > the (now temporarily empty) main list head? (presumably all under lock)
> 
> No. You move the items off the main list head and add it to the local
> list and they never go back. Just start processing that local list.
> Anything added to the main list after that will not get woken up by
> that current wake_all call. It will need to be woken by another wake_up.

OK.  But we may not run all of the wakeups, because of:

+                       if (++woken == nr_exclusive)
+                               break;

> 
> > 
> > What would need to be done as an unwind at the end of processing the
> > local list head before it disappears from existence?  Anything?
> 
> Not sure what you mean here.

Per above -- can't there be "orphaned" entries that only exist on the
local list head that didn't get processed?  What happens to those?

> 
> > 
> > > 
> > > > 
> > > > Also, I'm not entirely sure we want to do the cwait thing, it looks
> > > > painful.
> > > 
> > > Yeah, I have to think about that some more too. I'm currently sitting in
> > > the airport waiting for my final leg of my flight. After 18 hours of
> > > travel, it is probably not too wise to review this work in my current
> > > state ;-)
> > 
> > The alignment/parallel of existing mainline wait code seemed like the
> > consensus back ages ago when this was being discussed on IRC, but if
> > that has since changed, then I can adapt or abandon as required.  I long
> > ago learned that the time spent on something has no correlation to its
> > fitness or probability of being ready for addition to mainline.  :-)
> 
> heh, yeah. I'm guessing the point of all that is that anyone using the
> wake_queue() will default to the simple version? And then one would
> have to specify the complex version explicitly? But to do that we make
> all these funny steps?  May be OK, I still haven't spent much thought
> on it.

Yeah, that is pretty much it.  But the way it is done here lets us get
there without requiring tree wide changes or flag day type of changes
right out of the gate (which IMO tend to hinder adoption/integration).

P.
--

> 
> -- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/