From: Oleg Nesterov <oleg@tv-sign.ru>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Davide Libenzi <davidel@xmailserver.org>,
Ingo Molnar <mingo@elte.hu>, Roland McGrath <roland@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] fix the long standing exec vs kill race
Date: Mon, 3 Dec 2007 20:41:13 +0300 [thread overview]
Message-ID: <20071203174113.GA2674@tv-sign.ru> (raw)
In-Reply-To: <alpine.LFD.0.9999.0712030829240.8458@woody.linux-foundation.org>
On 12/03, Linus Torvalds wrote:
>
> On Sun, 2 Dec 2007, Oleg Nesterov wrote:
> >
> > Depends on
> > [PATCH] __group_complete_signal: fix coredump with group stop race
> > http://marc.info/?l=linux-kernel&m=119653436116036
> >
> > Needs review and testing.
> >
> > Please comment, I think at least the idea is promising.
>
> It looks clean and sane to me, but I'm currently more worried about
> 2.6.24, and even the first patch this depends on (coredump/stop race)
> makes me a bit nervous since all these things tend to have some rather
> subtle interactions with other parts that depended on the exact semantics
> of all the signal issues.
>
> So my gut feel - considering that none of the problems involved here are
> exactly new - is that this is good material for early in the 2.6.25 cycle.
>
> But I think the whole series looks ok, and if people press me and convince
> me it's (a) well tested and (b) needed early, then I guess it can be
> pushed into 2.6.24.
No, no, I don't think this should be pushed into 2.6.24 (even the first patch).
These problems are very old afaics, and nobody complained so far.
Even if correct, this needs more testing. I don't think this can break exec
or coredump in some "obvious" way, but I'm afraid this can introduce new
races / corner cases.
<offtopic>
I hope that with the new meaning of ->group_exit_task we can re-introduce the
"coredump signal "freezes" the thread group at sender's side" property, but we
need some hack to do this. OTOH, it was always a hack.
</offtopic>
Oleg.
prev parent reply other threads:[~2007-12-03 17:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-02 15:14 [PATCH 0/2] fix the long standing exec vs kill race Oleg Nesterov
2007-12-02 17:06 ` Simon Holm Thøgersen
2007-12-02 17:18 ` Oleg Nesterov
2007-12-02 18:08 ` Simon Holm Thøgersen
2007-12-02 18:52 ` Oleg Nesterov
2007-12-02 20:26 ` Linus Torvalds
2007-12-03 16:37 ` Linus Torvalds
2007-12-03 17:41 ` Oleg Nesterov [this message]
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=20071203174113.GA2674@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=akpm@linux-foundation.org \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=torvalds@linux-foundation.org \
/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.