From: Oleg Nesterov <oleg@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: jmoskovc@redhat.com, neilb@suse.de, benh@kernel.crashing.org,
gregkh@suse.de, takedakn@nttdata.co.jp,
linux-kernel@vger.kernel.org, spock@gentoo.org, mingo@redhat.com,
viro@zeniv.linux.org.uk, mfasheh@suse.com,
akpm@linux-foundation.org, t.sailer@alumni.ethz.ch,
shemminger@linux-foundation.org, menage@google.com,
abelay@mit.edu, drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] [PATCH 2/2] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 (v2)
Date: Mon, 1 Feb 2010 11:39:33 +0100 [thread overview]
Message-ID: <20100201103933.GA32188@redhat.com> (raw)
In-Reply-To: <20100201102936.GA31611@redhat.com>
On 02/01, Oleg Nesterov wrote:
>
> Oh. And in theory, it is better to change wait_for_helper(). It should
> do allow_signal(SIGCHLD) after kernel_thread(). Otherwise, kernel_thread()
> can fail if user-space sends SIGCHLD to the forking thread.
Well ;) And since allow_signal(SIGCHLD) was called, in theory we should
call sys_wait4() + clear_thread_flag(TIF_SIGPENDING) in a loop to protect
against the false SIGCHLD.
> > > Cough. And why call_usermodehelper_exec() has this strange ->path[0] == '\0'
> > > check?
> > >
> > That I can't explain. I figured I'd let that sleeping dog lie until this got
> > striaghtened out and fix it separately if it needed it
> > Neil
>
> Yes, yes, agreed. As I said, this has nothing to do with this series,
> even if I am right these (minor) bugs should be fixed separately.
Yes.
Oleg.
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
jmoskovc@redhat.com, mingo@redhat.com, drbd-dev@lists.linbit.com,
benh@kernel.crashing.org, t.sailer@alumni.ethz.ch,
abelay@mit.edu, gregkh@suse.de, spock@gentoo.org,
viro@zeniv.linux.org.uk, neilb@suse.de, mfasheh@suse.com,
menage@google.com, shemminger@linux-foundation.org,
takedakn@nttdata.co.jp
Subject: Re: [PATCH 2/2] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 (v2)
Date: Mon, 1 Feb 2010 11:39:33 +0100 [thread overview]
Message-ID: <20100201103933.GA32188@redhat.com> (raw)
In-Reply-To: <20100201102936.GA31611@redhat.com>
On 02/01, Oleg Nesterov wrote:
>
> Oh. And in theory, it is better to change wait_for_helper(). It should
> do allow_signal(SIGCHLD) after kernel_thread(). Otherwise, kernel_thread()
> can fail if user-space sends SIGCHLD to the forking thread.
Well ;) And since allow_signal(SIGCHLD) was called, in theory we should
call sys_wait4() + clear_thread_flag(TIF_SIGPENDING) in a loop to protect
against the false SIGCHLD.
> > > Cough. And why call_usermodehelper_exec() has this strange ->path[0] == '\0'
> > > check?
> > >
> > That I can't explain. I figured I'd let that sleeping dog lie until this got
> > striaghtened out and fix it separately if it needed it
> > Neil
>
> Yes, yes, agreed. As I said, this has nothing to do with this series,
> even if I am right these (minor) bugs should be fixed separately.
Yes.
Oleg.
next prev parent reply other threads:[~2010-02-01 10:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-21 20:08 [Drbd-dev] [PATCH] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 Neil Horman
2010-01-21 20:08 ` Neil Horman
2010-01-21 21:29 ` Thomas Sailer
2010-01-25 21:13 ` Neil Horman
2010-01-26 23:53 ` [Drbd-dev] " Andrew Morton
2010-01-26 23:53 ` Andrew Morton
2010-01-29 15:10 ` [Drbd-dev] [PATCH 0/2] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 (v2) Neil Horman
2010-01-29 15:10 ` Neil Horman
2010-01-29 15:13 ` [Drbd-dev] [PATCH 1/2] " Neil Horman
2010-01-29 15:13 ` Neil Horman
2010-01-31 14:46 ` [Drbd-dev] " Oleg Nesterov
2010-01-31 14:46 ` Oleg Nesterov
2010-01-31 15:41 ` [Drbd-dev] " Neil Horman
2010-01-31 15:41 ` Neil Horman
2010-01-29 15:14 ` [Drbd-dev] [PATCH 2/2] " Neil Horman
2010-01-29 15:14 ` Neil Horman
2010-01-31 15:50 ` [Drbd-dev] " Oleg Nesterov
2010-01-31 15:50 ` Oleg Nesterov
2010-01-31 17:41 ` [Drbd-dev] " Neil Horman
2010-01-31 17:41 ` Neil Horman
2010-02-01 10:29 ` [Drbd-dev] " Oleg Nesterov
2010-02-01 10:29 ` Oleg Nesterov
2010-02-01 10:39 ` Oleg Nesterov [this message]
2010-02-01 10:39 ` Oleg Nesterov
2010-02-01 13:16 ` [Drbd-dev] " Neil Horman
2010-02-01 13:16 ` Neil Horman
2010-02-01 14:18 ` [Drbd-dev] " Oleg Nesterov
2010-02-01 14:18 ` Oleg Nesterov
2010-02-02 19:19 ` [Drbd-dev] [PATCH 0/2] exec: refactor how call_usermodehelper works, and update the sense of the core_pipe recursion check (v3) Neil Horman
2010-02-02 19:19 ` Neil Horman
2010-02-02 19:20 ` [Drbd-dev] [PATCH 1/2] " Neil Horman
2010-02-02 19:20 ` Neil Horman
2010-02-03 20:09 ` [Drbd-dev] " Oleg Nesterov
2010-02-03 20:09 ` Oleg Nesterov
2010-02-02 19:21 ` [Drbd-dev] [PATCH 2/2] " Neil Horman
2010-02-02 19:21 ` Neil Horman
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=20100201103933.GA32188@redhat.com \
--to=oleg@redhat.com \
--cc=abelay@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=drbd-dev@lists.linbit.com \
--cc=gregkh@suse.de \
--cc=jmoskovc@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=mfasheh@suse.com \
--cc=mingo@redhat.com \
--cc=neilb@suse.de \
--cc=nhorman@tuxdriver.com \
--cc=shemminger@linux-foundation.org \
--cc=spock@gentoo.org \
--cc=t.sailer@alumni.ethz.ch \
--cc=takedakn@nttdata.co.jp \
--cc=viro@zeniv.linux.org.uk \
/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.