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  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:	Sat, 18 Oct 2014 19:05:19 -0400
From:	Steven Rostedt <>
To:	Peter Zijlstra <>
Cc:	Paul Gortmaker <>,,,
	Thomas Gleixner <>,
	Sebastian Andrzej Siewior <>,
	"Paul E. McKenney" <>
Subject: Re: [PATCH 3/7] wait.[ch]: Introduce the simple waitqueue (swait)

On Sat, 2014-10-18 at 23:34 +0200, Peter Zijlstra wrote:

> Same comment as before, that is an unbounded loop in a non preemptible
> section and therefore violates RT design principles.
> We actually did talk about ways of fixing that.

Right, and we should slap Paul for not showing up for it ;-)

The decision that we came up with was to splice the current list onto a
local list variable. And then we could go into a loop releasing the lock
and grabbing it again. Each time pop a waiter off the list and doing the
work of only one task at a time. This prevents doing large amounts of
wake ups under a spinlock. The splice is required to only wake up those
that are on the list when the wake up is called. This prevents waking up
a task twice because it woke up, removed itself, and then added itself
again. We must keep the semantics that a wake up only wakes up a task

> 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 ;-)

-- Steve

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists