linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: arjan@linux.intel.com, richard@nod.at,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] kmod: Avoid deadlock by recursive kmod call.
Date: Wed, 18 Jan 2012 16:45:58 -0800	[thread overview]
Message-ID: <20120118164558.a10d7821.akpm@linux-foundation.org> (raw)
In-Reply-To: <201201062139.JFC73472.SMQFOFOFHLVOtJ@I-love.SAKURA.ne.jp>

On Fri, 6 Jan 2012 21:39:17 +0900
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:

> Tetsuo Handa wrote:
> > An example operation for triggering this deadlock:
> > 
> >   # : > /tmp/dummy
> >   # chmod 755 /tmp/dummy
> >   # echo /tmp/dummy > /proc/sys/kernel/hotplug
> >   # modprobe whatever
> 
> I wrote two patches. Please review.
> 
> ----- Patch A start -----
> [PATCH v3] kmod: Avoid deadlock by recursive kmod call.
> 
> The system deadlocks when call_usermodehelper(UMH_WAIT_EXEC) request triggered
> call_usermodehelper(UMH_WAIT_PROC) request.
> 
> This is because "khelper thread is waiting at wait_for_completion() in
> do_fork() since the worker thread was created with CLONE_VFORK flag" and
> "the worker thread cannot call complete() because do_execve() is blocked at
> UMH_WAIT_PROC request (e.g. request_module() from search_binary_handler())" and
> "the khelper thread cannot start processing UMH_WAIT_PROC request because
> the khelper thread is waiting at wait_for_completion() in do_fork()".
> 
> In order to avoid deadlock, do not try to call wait_for_completion() in
> call_usermodehelper_exec() if the worker thread was created by khelper thread
> with CLONE_VFORK flag.

I suppose we should fix this, although it's obscure.

The changelog doesn't tell people how the bug might occur, which is
bad.  I suggest adding this text to it:

: This bug was observed when using a corrupted /sbin/hotplug binary.  The
: corrupted binary caused a call to request_module("binfmt-0000"). 
: search_binary_handler() uses UMH_WAIT_EXEC.
: 
: An example operation for triggering this deadlock:
: 
:    # : > /tmp/dummy
:    # chmod 755 /tmp/dummy
:    # echo /tmp/dummy > /proc/sys/kernel/hotplug
:    # modprobe whatever

which might be inaccurate/inadequate.  I didn't try very hard.  Please
provide a complete description and analysis of the bug.

I prefer patch A - all that poking around at stack slots is hacky.

> --- linux-3.2.orig/fs/exec.c
> +++ linux-3.2/fs/exec.c
> @@ -1406,6 +1406,7 @@ int search_binary_handler(struct linux_b
>  					fput(bprm->file);
>  				bprm->file = NULL;
>  				current->did_exec = 1;
> +				current->kmod_thread = 0;
>  				proc_exec_connector(current);
>  				return retval;
>  			}

Special-casing this assignment down in this particular client of kmod
looks bad.  We need to find somewhere else to do this.  Perferably
within the kmod code itself, or possibly over in exec.c or fork.c.


  parent reply	other threads:[~2012-01-19  0:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-27  7:01 [3.1.6] Deadlock upon recursive call_usermodehelper_exec() penguin-kernel
2011-12-27  8:14 ` Tetsuo Handa
2012-01-04  7:43 ` [PATCH] kmod: Avoid deadlock by recursive kmod call Tetsuo Handa
2012-01-04 13:08   ` [PATCH v2] " Tetsuo Handa
     [not found]     ` <201201062139.JFC73472.SMQFOFOFHLVOtJ@I-love.SAKURA.ne.jp>
2012-01-19  0:45       ` Andrew Morton [this message]
2012-01-19  2:07         ` [PATCH v3] " Tetsuo Handa
2012-01-24  4:32           ` [PATCH v4] " Tetsuo Handa
2012-01-26  0:40             ` Andrew Morton
2012-01-26  1:32               ` Tetsuo Handa

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=20120118164558.a10d7821.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=richard@nod.at \
    /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;
as well as URLs for NNTP newsgroup(s).