From: Roland McGrath <roland@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"Metzger, Markus T" <markus.t.metzger@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] move exit_ptrace() from forget_original_parent() to do_exit()
Date: Thu, 19 Feb 2009 18:28:32 -0800 (PST) [thread overview]
Message-ID: <20090220022832.CA587FC2F7@magilla.sf.frob.com> (raw)
In-Reply-To: Oleg Nesterov's message of Wednesday, 11 February 2009 22:12:21 +0100 <20090211211221.GA16857@redhat.com>
> If we ever change exit_ptrace() to do the blocking calls, it makes
> sense to move it after exit_signals().
I'm not sure I understand this comment. I guess you just mean that if we
block, we should be sure to do the exit_signals() pass-the-pending-buck
work afterwards. OK. But I think we want it after exit_signals anyway so
that ptrace_traceme() can check PF_EXITING (cf 1/4 review).
Also, I think this patch should be the very last of the series. The others
reorganize code but we don't think they really reorder anything. This one
we thinks reorders things in a way that's fine, but it clearly does a big
shift of the ordering of where ptrace cleanups happen relative to lots of
other tear-down. So that seems the most likely to cause some unimagined
subtle regression down the line. If it comes to a bisect that hits this
patch, I think we'd rather be comparing one with all those tweaks to
forget_original_parent merged in as the baseline than juggling their
incremental effects after this one's big reordering.
Thanks,
Roland
next prev parent reply other threads:[~2009-02-20 2:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-11 21:12 [PATCH 3/4] move exit_ptrace() from forget_original_parent() to do_exit() Oleg Nesterov
2009-02-20 2:28 ` Roland McGrath [this message]
2009-02-23 16:59 ` 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=20090220022832.CA587FC2F7@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markus.t.metzger@intel.com \
--cc=oleg@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.