From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754685AbbGISHv (ORCPT ); Thu, 9 Jul 2015 14:07:51 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:34901 "EHLO mail-wg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754159AbbGISH2 (ORCPT ); Thu, 9 Jul 2015 14:07:28 -0400 From: Frederic Weisbecker To: LKML Cc: Frederic Weisbecker , Oleg Nesterov , Christoph Lameter , Rik van Riel , Andrew Morton Subject: [PATCH 3/5] kmod: Add up-to-date explanations on the purpose of each asynchronous levels Date: Thu, 9 Jul 2015 20:07:15 +0200 Message-Id: <1436465237-22031-4-git-send-email-fweisbec@gmail.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1436465237-22031-1-git-send-email-fweisbec@gmail.com> References: <1436465237-22031-1-git-send-email-fweisbec@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org There seem to be quite some confusions on the comments, likely due to changes that came after them. Now since it's very non obvious why we have 3 levels of asynchronous code to implement usermodehelpers, it's important to comment in detail the reason of this layout. Cc: Rik van Riel Cc: Oleg Nesterov Cc: Andrew Morton Cc: Christoph Lameter Signed-off-by: Frederic Weisbecker --- kernel/kmod.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/kernel/kmod.c b/kernel/kmod.c index d8cc116ab..9ffb24c 100644 --- a/kernel/kmod.c +++ b/kernel/kmod.c @@ -221,12 +221,12 @@ static int call_usermodehelper_exec_async(void *data) flush_signal_handlers(current, 1); spin_unlock_irq(¤t->sighand->siglock); - /* We can run anywhere, unlike our parent keventd(). */ + /* We can run anywhere, unlike our parent (unbound workqueue). */ set_cpus_allowed_ptr(current, cpu_all_mask); /* - * Our parent is keventd, which runs with elevated scheduling priority. - * Avoid propagating that into the userspace child. + * Our parent is the unbound workqueue, which runs with elevated + * scheduling priority. Avoid propagating that into the userspace child. */ set_user_nice(current, 0); @@ -267,7 +267,7 @@ out: do_exit(0); } -/* Keventd can't block, but this (a child) can. */ +/* Handles UMH_WAIT_PROC. */ static int call_usermodehelper_exec_sync(void *data) { struct subprocess_info *sub_info = data; @@ -283,8 +283,8 @@ 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 keventd, - * and put_user() to a kernel address works OK for kernel + * 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. * @@ -305,7 +305,16 @@ static int call_usermodehelper_exec_sync(void *data) do_exit(0); } -/* This is run by khelper thread */ +/* + * This function doesn't strictly need to be called asynchronously. But we + * need to create the usermodehelper kernel threads from a task that is affine + * to all 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 any busy CPU. + * + * Unbound workqueues provide such wide affinity. + */ static void call_usermodehelper_exec_work(struct work_struct *work) { struct subprocess_info *sub_info = @@ -533,7 +542,7 @@ EXPORT_SYMBOL(call_usermodehelper_setup); * from interrupt context. * * Runs a user-space application. The application is started - * asynchronously if wait is not set, and runs as a child of keventd. + * asynchronously if wait is not set, and runs as a child of unbound workqueues. * (ie. it runs with full root capabilities). */ int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait) -- 2.1.4