From: Oleg Nesterov <oleg@redhat.com>
To: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
matt.helsley@gmail.com, davem@davemloft.net,
guillaume@morinfr.org
Subject: Re: + exitc-call-proc_exit_connector-after-exit_state-is-set.patch added to -mm tree
Date: Thu, 27 Feb 2014 17:47:50 +0100 [thread overview]
Message-ID: <20140227164750.GC909@redhat.com> (raw)
In-Reply-To: <20140227144826.GA13313@bender.morinfr.org>
On 02/27, Guillaume Morin wrote:
>
> On 25 Feb 16:10, Oleg Nesterov wrote:
> > > pid_t pid = fork();
> > > if (pid > 0) {
> > > register_interest_for_pid(pid);
> > > if (waitpid(pid, NULL, WNOHANG) > 0)
> > > {
> > > /* We might have raced with exit() */
> > > }
> >
> > Just in case... Even with this patch the code above is still "racy" if the
> > child is multi-threaded. Plus it should obviously filter-out subthreads.
> > And afaics there is no way to make it reliable, even if you change the
> > code above so that waitpid() is called only after the last thread exits
> > WNOHANG still can fail.
> > Not that I am not arguing with this change. Although I hope that someone
> > can confirm that netlink_broadcast() is safe even if release_task(current)
> > was already called, so that the caller has no pids, sighand, is not visible
> > via /proc/, etc.
>
> I was too succinct, I think. What I am trying to do is to close a race
> when a short-lived *process* dies before register_interest_for_pid()
> interprets the connector message correctly, (i.e realizes this is an
> exit message for a pid that the parent created).
Yes, I misunderstood the changelog, thanks.
Anyway, I only tried to say that "a small window between when the event
is delivered and the child become wait()-able." is not closed by this
patch. Sorry for not being clear enough.
> You clarified for me that a ptraced process is a case where this race
> could still happen. That's a good point. Fortunately, in the case of a
> short-lived process, this is not a common scenario.
OK.
> You seem to say it's possible for all threads to have completed
> exit_notify() and sent their exit message to the connector before
> register_interest_for_pid() does its job and still have waitpid(WNOHANG)
> fails. Is it correct?
And I indeed said this, but I was wrong ;) Sorry. somehow I forgot
that with this patch release_task(sub_thread) is always called before
proc_exit_connector() (and I even asked if this is safe above).
However, I still do not see how you can ensure that all threads have
already exited to rely on WNOHANG.
Nevermind. Please consider this trivial example:
tfunc(void *)
{
for (;;)
pause();
}
int main(void)
{
pthread_create(tfunc);
pthread_exit();
}
The main thread can exit and call proc_exit_connector() before
register_interest_for_pid(), but WNOHANG obviously can't succeed.
So I am still not sure this patch can solve the problem you described.
But let me repeat just in case: I am not arguing with this change.
Oleg.
next prev parent reply other threads:[~2014-02-27 16:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <530bbf59.78aTdR6Ql6kCpXnE%akpm@linux-foundation.org>
2014-02-25 15:10 ` + exitc-call-proc_exit_connector-after-exit_state-is-set.patch added to -mm tree Oleg Nesterov
2014-02-27 14:48 ` Guillaume Morin
2014-02-27 16:47 ` Oleg Nesterov [this message]
2014-02-27 18:26 ` Guillaume Morin
2014-02-27 19:06 ` 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=20140227164750.GC909@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=guillaume@morinfr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.helsley@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox