From: Frederic Weisbecker <fweisbec@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Tejun Heo <tj@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
Christoph Lameter <cl@linux.com>, Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH 5/5] kmod: Handle UMH_WAIT_PROC from system unbound workqueue
Date: Mon, 27 Jul 2015 18:27:20 +0200 [thread overview]
Message-ID: <1438014440-20669-6-git-send-email-fweisbec@gmail.com> (raw)
In-Reply-To: <1438014440-20669-1-git-send-email-fweisbec@gmail.com>
The UMH_WAIT_PROC handler runs in its own thread in order to make sure
that waiting for the exec kernel thread completion won't block other
usermodehelper queued jobs.
On older workqueue implementations, worklets couldn't sleep without
blocking the rest of the queue. But now the workqueue subsystem handles
that. Khelper still had the older limitation due to its singlethread
properties but we replaced it to system unbound workqueues.
Those are affine to the current node and can block up to some number
of instances.
They are a good candidate to handle UMH_WAIT_PROC assuming that we have
enough system unbound workers to handle lots of parallel usermodehelper
jobs.
Cc: Rik van Riel <riel@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
---
kernel/kmod.c | 44 ++++++++++++++++++++------------------------
1 file changed, 20 insertions(+), 24 deletions(-)
diff --git a/kernel/kmod.c b/kernel/kmod.c
index ccf60cc..c1f2550 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -264,15 +264,9 @@ out:
do_exit(0);
}
-/*
- * Handles UMH_WAIT_PROC. Our parent (unbound workqueue) might not be able to
- * run enough instances to handle usermodehelper completions without blocking
- * some other pending requests. That's why we use a kernel thread dedicated for
- * that purpose.
- */
-static int call_usermodehelper_exec_sync(void *data)
+/* Handles UMH_WAIT_PROC. */
+static void call_usermodehelper_exec_sync(struct subprocess_info *sub_info)
{
- struct subprocess_info *sub_info = data;
pid_t pid;
/* If SIGCLD is ignored sys_wait4 won't populate the status. */
@@ -286,9 +280,9 @@ static int call_usermodehelper_exec_sync(void *data)
* Normally it is bogus to call wait4() from in-kernel because
* wait4() wants to write the exit code to a userspace address.
* But call_usermodehelper_exec_sync() always runs as kernel
- * thread and put_user() to a kernel address works OK for kernel
- * threads, due to their having an mm_segment_t which spans the
- * entire address space.
+ * thread (workqueue) and put_user() to a kernel address works
+ * OK for kernel threads, due to their having an mm_segment_t
+ * which spans the entire address space.
*
* Thus the __user pointer cast is valid here.
*/
@@ -303,19 +297,21 @@ static int call_usermodehelper_exec_sync(void *data)
sub_info->retval = ret;
}
+ /* Restore default kernel sig handler */
+ kernel_sigaction(SIGCHLD, SIG_IGN);
+
umh_complete(sub_info);
- do_exit(0);
}
/*
- * This function doesn't strictly needs to be called asynchronously. But we
- * need to create the usermodehelper kernel threads from a task that is affine
+ * We need to create the usermodehelper kernel thread from a task that is affine
* to an optimized set of CPUs (or nohz housekeeping ones) such that they
* inherit a widest affinity irrespective of call_usermodehelper() callers with
* possibly reduced affinity (eg: per-cpu workqueues). We don't want
* usermodehelper targets to contend a busy CPU.
*
- * Unbound workqueues provide such wide affinity.
+ * Unbound workqueues provide such wide affinity and allow to block on
+ * UMH_WAIT_PROC requests without blocking pending request (up to some limit).
*
* Besides, workqueues provide the privilege level that caller might not have
* to perform the usermodehelper request.
@@ -325,18 +321,18 @@ static void call_usermodehelper_exec_work(struct work_struct *work)
{
struct subprocess_info *sub_info =
container_of(work, struct subprocess_info, work);
- pid_t pid;
- if (sub_info->wait & UMH_WAIT_PROC)
- pid = kernel_thread(call_usermodehelper_exec_sync, sub_info,
- CLONE_FS | CLONE_FILES | SIGCHLD);
- else
+ if (sub_info->wait & UMH_WAIT_PROC) {
+ call_usermodehelper_exec_sync(sub_info);
+ } else {
+ pid_t pid;
+
pid = kernel_thread(call_usermodehelper_exec_async, sub_info,
SIGCHLD);
-
- if (pid < 0) {
- sub_info->retval = pid;
- umh_complete(sub_info);
+ if (pid < 0) {
+ sub_info->retval = pid;
+ umh_complete(sub_info);
+ }
}
}
--
2.1.4
next prev parent reply other threads:[~2015-07-27 16:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 16:27 [PATCH 0/5] kmod: Cleanups, simplifications, and make isolation friendly v3 Frederic Weisbecker
2015-07-27 16:27 ` [PATCH 1/5] kmod: Bunch of internal functions renames Frederic Weisbecker
2015-07-27 16:27 ` [PATCH 2/5] kmod: Remove unecessary explicit wide CPU affinity setting Frederic Weisbecker
2015-07-27 16:27 ` [PATCH 3/5] kmod: Add up-to-date explanations on the purpose of each asynchronous levels Frederic Weisbecker
2015-07-27 16:27 ` [PATCH 4/5] kmod: Use system_unbound_wq instead of khelper Frederic Weisbecker
2015-07-27 16:27 ` Frederic Weisbecker [this message]
2015-07-27 18:48 ` [PATCH 0/5] kmod: Cleanups, simplifications, and make isolation friendly v3 Tejun Heo
2015-07-27 21:05 ` Frederic Weisbecker
2015-07-28 18:01 ` Tejun Heo
2015-07-28 18:07 ` Frederic Weisbecker
2015-08-05 17:10 ` Oleg Nesterov
2015-08-05 22:14 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1438014440-20669-6-git-send-email-fweisbec@gmail.com \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=riel@redhat.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome