Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754342AbbGISID (ORCPT ); Thu, 9 Jul 2015 14:08:03 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:33070 "EHLO mail-wg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754278AbbGISHb (ORCPT ); Thu, 9 Jul 2015 14:07:31 -0400 From: Frederic Weisbecker To: LKML Cc: Frederic Weisbecker , Oleg Nesterov , Christoph Lameter , Rik van Riel , Andrew Morton Subject: [RFC PATCH 5/5] kmod: Handle UMH_WAIT_PROC from system unbound workqueue Date: Thu, 9 Jul 2015 20:07:17 +0200 Message-Id: <1436465237-22031-6-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 Content-Length: 3126 Lines: 96 The UMH_WAIT_PROC handler runs in its own thread for obsolete reasons. We couldn't launch and then wait for the exec kernel thread completion without blocking other usermodehelper queued jobs since khelper was implemented as a singlthread ordered workqueue. But now we replaced khelper with generic system unbound workqueues which can handle concurrent blocking jobs. So lets run it from the workqueue. CHECK: I'm just worried about the signal handler that gets tweaked and also the call to sys_wait() that might fiddle with internals. The system workqueue must continue to work without surprise for other works. Cc: Rik van Riel Cc: Oleg Nesterov Cc: Andrew Morton Cc: Christoph Lameter Signed-off-by: Frederic Weisbecker --- kernel/kmod.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/kernel/kmod.c b/kernel/kmod.c index d190178..a8bf872 100644 --- a/kernel/kmod.c +++ b/kernel/kmod.c @@ -265,9 +265,8 @@ out: } /* Handles UMH_WAIT_PROC. */ -static int call_usermodehelper_exec_sync(void *data) +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. */ @@ -281,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. */ @@ -299,7 +298,6 @@ static int call_usermodehelper_exec_sync(void *data) } umh_complete(sub_info); - do_exit(0); } /* @@ -316,18 +314,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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/