linux-kernel - [RFC PATCH 5/5] kmod: Handle UMH_WAIT_PROC from system unbound workqueue

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <1436465237-22031-6-git-send-email-fweisbec@gmail.com>
Date:	Thu,  9 Jul 2015 20:07:17 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Christoph Lameter <cl@...ux.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: [RFC PATCH 5/5] kmod: Handle UMH_WAIT_PROC from system unbound workqueue

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 <riel@...hat.com>
Cc: Oleg Nesterov <oleg@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Christoph Lameter <cl@...ux.com>
Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
---
 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/