| 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
| ||
|
Date: Tue, 28 Jul 2015 16:39:17 +0200
From: Petr Mladek <pmladek@...e.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Josh Triplett <josh@...htriplett.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jiri Kosina <jkosina@...e.cz>, Borislav Petkov <bp@...e.de>,
Michal Hocko <mhocko@...e.cz>, linux-mm@...ck.org,
Vlastimil Babka <vbabka@...e.cz>,
live-patching@...r.kernel.org, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org, Petr Mladek <pmladek@...e.com>
Subject: [RFC PATCH 00/14] kthread: Use kthread worker API more widely
Kthreads are currently implemented as an infinite loop. Each
has its own variant of checks for terminating, freezing,
awakening. Sometimes, it is hard to say if they are done
correctly. They are also harder to maintain if there is
a generic problem found in the area.
I have proposed a so-called kthread iterant API to improve the situation,
see https://lkml.org/lkml/2015/6/5/555. The RFC opened and/or answered
several questions.
This RFC is reaction on Tejun's suggestion to use the existing kthread
worker API instead of a new one, see https://lkml.org/lkml/2015/6/9/77.
I wanted to give it a try.
Structure of this patch set:
----------------------------
1st..6th patches: improve the existing kthread worker API
7th, 8th, 11th patches: converts three kthreads into the new API,
namely: RCU gp kthreas, khugepaged, my favorite ring buffer
benchmark
12th..14th patches: show how we could further improve the API
9th, 10th patches: do some further clean up of the ring buffer
benchmark; they allow easier conversion into the new API;
but they might be applied independently
TODO:
-----
If people like the kthread worker API, it will need more love.
The following ideas come to my mind:
+ allow to pass void *data via struct kthread_work;
+ hide struct kthread_worker in kthread.c and make the API
more safe
+ allow to cancel work
I have tested this patches against today's Linux tree, aka 4.2.0-rc4+.
Petr Mladek (14):
kthread: Allow to call __kthread_create_on_node() with va_list args
kthread: Add create_kthread_worker*()
kthread: Add drain_kthread_worker()
kthread: Add destroy_kthread_worker()
kthread: Add wakeup_and_destroy_kthread_worker()
kthread: Add kthread_worker_created()
mm/huge_page: Convert khugepaged() into kthread worker API
rcu: Convert RCU gp kthreads into kthread worker API
ring_buffer: Initialize completions statically in the benchmark
ring_buffer: Fix more races when terminating the producer in the
benchmark
ring_buffer: Use kthread worker API for the producer kthread in the
benchmark
kthread_worker: Better support freezable kthread workers
kthread_worker: Add set_kthread_worker_user_nice()
kthread_worker: Add set_kthread_worker_scheduler*()
include/linux/kthread.h | 29 +++
kernel/kthread.c | 359 +++++++++++++++++++++++++++++++----
kernel/rcu/tree.c | 182 +++++++++---------
kernel/rcu/tree.h | 4 +-
kernel/trace/ring_buffer_benchmark.c | 150 ++++++++-------
mm/huge_memory.c | 83 ++++----
6 files changed, 584 insertions(+), 223 deletions(-)
--
1.8.5.6
--
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