]> git.baikalelectronics.ru Git - kernel.git/commit
Restore call_usermodehelper_pipe() behaviour
authorMichael Ellerman <michael@ellerman.id.au>
Tue, 11 Sep 2007 22:23:51 +0000 (15:23 -0700)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Wed, 12 Sep 2007 00:21:20 +0000 (17:21 -0700)
commitc60225329e26f79718272115472ab7a4edf64bb9
treee7f928376db3d0c72413760fe2232b9a50fa08b1
parent74abf547d319aab88d03f0988dff8b9188cffb32
Restore call_usermodehelper_pipe() behaviour

The semantics of call_usermodehelper_pipe() used to be that it would fork
the helper, and wait for the kernel thread to be started.  This was
implemented by setting sub_info.wait to 0 (implicitly), and doing a
wait_for_completion().

As part of the cleanup done in 9c17d3c19c42166e343337b1a2501d2e578d7a7c,
call_usermodehelper_pipe() was changed to pass 1 as the value for wait to
call_usermodehelper_exec().

This is equivalent to setting sub_info.wait to 1, which is a change from
the previous behaviour.  Using 1 instead of 0 causes
__call_usermodehelper() to start the kernel thread running
wait_for_helper(), rather than directly calling ____call_usermodehelper().

The end result is that the calling kernel code blocks until the user mode
helper finishes.  As the helper is expecting input on stdin, and now no one
is writing anything, everything locks up (observed in do_coredump).

The fix is to change the 1 to UMH_WAIT_EXEC (aka 0), indicating that we
want to wait for the kernel thread to be started, but not for the helper to
finish.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
kernel/kmod.c