lkml.org 
[lkml]   [2007]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] ____call_usermodehelper: don't flush_signals()
    On 02/27, Rusty Russell wrote:
    >
    > On Tue, 2007-02-27 at 00:53 +0300, Oleg Nesterov wrote:
    > > ____call_usermodehelper() has no reason for flush_signals(). It is a fresh
    > > forked process which is going to exec a user-space application or exit on
    > > failure.
    >
    > And the flush_signal_handlers() call?

    Well... flush_old_exec() calls flush_signal_handlers(force_default = 0),
    this is not enough. We don't want to start user-space application with
    SIGKILL ignored (yes, parent doesn't ignores it currently).

    > Your patch looks correct; this code was presumably lying around from
    > before someone (I?) adapted this code to use kthread.

    Thanks! What I can't understand is why kthread/daemonize block all signals.
    This doesn't look good to me. This can't prevent signal delivery, this only
    blocks signal_wake_up(). We can even set SIGNAL_GROUP_EXIT for the kernel
    thread. Of course, only root can do that, but isn't it better to just ignore
    all signals instead of blocking them?

    Note that we can't free the memory if we send a signal to (for example)
    khelper.

    Oleg.

    -
    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/

    \
     
     \ /
      Last update: 2007-02-27 10:25    [W:0.041 / U:0.808 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site