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]
Message-ID: <20141020114013.31e5137c@gandalf.local.home>
Date:	Mon, 20 Oct 2014 11:40:13 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
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

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.

> 
> 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.

> 
> > 
> > > 
> > > 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.

-- 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ