linux-kernel - [tip:sched/urgent] sched/swait: Document it clearly that the swait facilities are special and shouldn't be used

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: <tip-88796e7e5c457cae72833196cb98e6895dd107e2@git.kernel.org>
Date:   Mon, 23 Oct 2017 05:45:34 -0700
From:   tip-bot for Davidlohr Bueso <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     peterz@...radead.org, paulmck@...ux.vnet.ibm.com,
        tglx@...utronix.de, torvalds@...ux-foundation.org, hpa@...or.com,
        mcgrof@...nel.org, linux-kernel@...r.kernel.org,
        akpm@...ux-foundation.org, mingo@...nel.org, dave@...olabs.net,
        dbueso@...e.de
Subject: [tip:sched/urgent] sched/swait: Document it clearly that the swait
 facilities are special and shouldn't be used

Commit-ID:  88796e7e5c457cae72833196cb98e6895dd107e2
Gitweb:     https://git.kernel.org/tip/88796e7e5c457cae72833196cb98e6895dd107e2
Author:     Davidlohr Bueso <dave@...olabs.net>
AuthorDate: Fri, 20 Oct 2017 10:13:46 -0700
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Mon, 23 Oct 2017 13:59:21 +0200

sched/swait: Document it clearly that the swait facilities are special and shouldn't be used

We currently welcome using swait over wait whenever possible because
it is a slimmer data structure. However, Linus has made it very clear
that he does not want this used, unless under very specific RT scenarios
(such as current users).

Update the comments before kernel hipsters start thinking swait is the
cool thing to do.

Signed-off-by: Davidlohr Bueso <dbueso@...e.de>
Acked-by: Luis R. Rodriguez <mcgrof@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: dave@...olabs.net
Cc: wagi@...om.org
Link: http://lkml.kernel.org/r/20171020171346.24445-1-dave@stgolabs.net
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 include/linux/swait.h | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/include/linux/swait.h b/include/linux/swait.h
index 73e97a0..cf30f502 100644
--- a/include/linux/swait.h
+++ b/include/linux/swait.h
@@ -9,13 +9,16 @@
 /*
  * Simple wait queues
  *
- * While these are very similar to the other/complex wait queues (wait.h) the
- * most important difference is that the simple waitqueue allows for
- * deterministic behaviour -- IOW it has strictly bounded IRQ and lock hold
- * times.
+ * While these are very similar to regular wait queues (wait.h) the most
+ * important difference is that the simple waitqueue allows for deterministic
+ * behaviour -- IOW it has strictly bounded IRQ and lock hold times.
  *
- * In order to make this so, we had to drop a fair number of features of the
- * other waitqueue code; notably:
+ * Mainly, this is accomplished by two things. Firstly not allowing swake_up_all
+ * from IRQ disabled, and dropping the lock upon every wakeup, giving a higher
+ * priority task a chance to run.
+ *
+ * Secondly, we had to drop a fair number of features of the other waitqueue
+ * code; notably:
  *
  *  - mixing INTERRUPTIBLE and UNINTERRUPTIBLE sleeps on the same waitqueue;
  *    all wakeups are TASK_NORMAL in order to avoid O(n) lookups for the right
@@ -24,12 +27,14 @@
  *  - the exclusive mode; because this requires preserving the list order
  *    and this is hard.
  *
- *  - custom wake functions; because you cannot give any guarantees about
- *    random code.
- *
- * As a side effect of this; the data structures are slimmer.
+ *  - custom wake callback functions; because you cannot give any guarantees
+ *    about random code. This also allows swait to be used in RT, such that
+ *    raw spinlock can be used for the swait queue head.
  *
- * One would recommend using this wait queue where possible.
+ * As a side effect of these; the data structures are slimmer albeit more ad-hoc.
+ * For all the above, note that simple wait queues should _only_ be used under
+ * very specific realtime constraints -- it is best to stick with the regular
+ * wait queues in most cases.
  */
 
 struct task_struct;