All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, andi@firstfloor.org,
	David Howells <dhowells@redhat.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	Roland McGrath <roland@redhat.com>
Subject: [PATCH 3/6] call_usermodehelper: no need to unblock signals
Date: Mon, 15 Mar 2010 20:47:39 +0100	[thread overview]
Message-ID: <20100315194739.GD10896@redhat.com> (raw)
In-Reply-To: <20100315194609.GA10896@redhat.com>

____call_usermodehelper() correctly calls flush_signal_handlers()
to set SIG_DFL, but sigemptyset(->blocked) and recalc_sigpending()
are not needed.

This kthread was forked by workqueue thread, all signals must be
unblocked and ignored, no pending signal is possible.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---

 kernel/kmod.c |    3 ---
 1 file changed, 3 deletions(-)

--- 34-rc1/kernel/kmod.c~3_DONT_UNBLOCK	2010-03-15 20:10:12.000000000 +0100
+++ 34-rc1/kernel/kmod.c	2010-03-15 20:17:47.000000000 +0100
@@ -134,11 +134,8 @@ static int ____call_usermodehelper(void 
 	struct subprocess_info *sub_info = data;
 	int retval;
 
-	/* Unblock all signals */
 	spin_lock_irq(&current->sighand->siglock);
 	flush_signal_handlers(current, 1);
-	sigemptyset(&current->blocked);
-	recalc_sigpending();
 	spin_unlock_irq(&current->sighand->siglock);
 
 	/* We can run anywhere, unlike our parent keventd(). */


  parent reply	other threads:[~2010-03-15 19:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15 12:29 [PATCH 0/2] exec: refactor how call_usermodehelper works, and update the sense of the core_pipe recursion check (v4 rediff) Neil Horman
2010-03-15 12:33 ` [PATCH 1/2] kmod: add init function to usermodehelper Neil Horman
2010-03-15 17:34   ` Oleg Nesterov
2010-03-15 17:56     ` Neil Horman
2010-03-15 12:36 ` [PATCH 2/2] exec: replace call_usermodehelper_pipe with use of umh init function and resolve limit Neil Horman
2010-03-15 17:39   ` Oleg Nesterov
2010-03-15 19:46 ` [PATCH 0/6] umh: keys, signals, misc Oleg Nesterov
2010-03-15 19:46   ` [PATCH 1/6] umh: creds: convert call_usermodehelper_keys() to use subprocess_info->init() Oleg Nesterov
2010-03-15 19:47   ` [PATCH 2/6] umh: creds: kill subprocess_info->cred logic Oleg Nesterov
2010-03-15 19:47   ` Oleg Nesterov [this message]
2010-03-15 19:48   ` [PATCH 4/6] wait_for_helper: SIGCHLD from user-space can lead to use-after-free Oleg Nesterov
2010-03-15 19:48   ` [PATCH 5/6] call_usermodehelper: simplify/fix UMH_NO_WAIT case Oleg Nesterov
2010-03-15 19:49   ` [PATCH 6/6] call_usermodehelper: UMH_WAIT_EXEC ignores kernel_thread() failure Oleg Nesterov
2010-03-16 19:37   ` [PATCH 0/4] do_coredump: cleanups Oleg Nesterov
2010-03-16 19:38     ` [PATCH 1/4] coredump: factor out the not-ispipe file checks Oleg Nesterov
2010-03-16 19:38     ` [PATCH 2/4] coredump: cleanup "ispipe" code Oleg Nesterov
2010-03-16 19:39     ` [PATCH 3/4] coredump: factor out put_cred() calls Oleg Nesterov
2010-03-16 19:39     ` [PATCH 4/4] coredump: shift down_write(mmap_sem) into coredump_wait() Oleg Nesterov

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=20100315194739.GD10896@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=roland@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.