linux-kernel - Re: [PATCH 1/3] wait-simple: Introduce the simple waitqueue 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:	Thu, 12 Dec 2013 09:48:06 -0500
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Christoph Hellwig <hch@...radead.org>
CC:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] wait-simple: Introduce the simple waitqueue implementation

On 13-12-12 05:56 AM, Thomas Gleixner wrote:
> On Thu, 12 Dec 2013, Christoph Hellwig wrote:
> 
>> On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
>>> From: Thomas Gleixner <tglx@...utronix.de>
>>>
>>> The wait_queue is a swiss army knife and in most of the cases the
>>> full complexity is not needed.  Here we provide a slim version, as
>>> it lowers memory consumption and runtime overhead.
>>
>> Might it make more sense to just make the simple one the default and use
>> the complex one in the few cases that need it?
> 
> Sure.

The one major downside of doing it that way, is that it becomes
a flag day event instead of a gradual roll out.  Any unexpected
fallout will bisect to the one commit, which kind of would suck,
if we happen to trigger something kooky like the 50w mwait issue,
or break the usb stack somehow.

If we do the flag day type change, where complex wait is what we
have currently, and simple wait is the default, then I guess the
logistics would be something like:

1) git mv wait.[ch] --- > cwait.[ch]
   make an empty wait.h include cwait.h temporarily

2) rename all existing functions in cwait.[ch] to have an added
  "c" prefix (or similar)
   
   in wait.h, temporarily add a bunch of things like
          #define wait_xyz  cwait_xyz
   so that things still compile and link.

3) track down the users who really need the extra complexity
   and have them use cwait calls and include cwait.h

4) bring in the simple wait queue support as wait.c and wait.h
   and delete the defines added in step two.  This will be the
   flag day commit.

Is that what we want to do here?

Paul.
--

>  
>> It would also be good to enumerate those cases.  The wake callbacks come
>> to mind, but I guess there are more?
> 
> You can convert everything which uses default_wake_function and does
> not use the exclusive wait trickery.
> 
> Thanks,
> 
> 	tglx
> 
--
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/