All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jerome Marchand <jmarchan@redhat.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] ptrace: reintroduce __ptrace_detach() as a callee of ptrace_exit()
Date: Thu, 5 Feb 2009 23:06:56 +0100	[thread overview]
Message-ID: <20090205220656.GA7660@redhat.com> (raw)
In-Reply-To: <20090205203731.1E02BFC381@magilla.sf.frob.com>

On 02/05, Roland McGrath wrote:
>
> > > Given its content, this function now better belongs in ptrace.c, I think.
> >
> > I don't completely agree... This helper imho has nothing to do with
> > ptracing, except it does __ptrace_unlink(). But OK, I will move it
> > if you prefer.
>
> Obviously where it goes is not a big deal.  But I think it's clear that it
> has everything to do with ptrace and nothing to do with anything else.
> It resolves a situation that can only arise because of ptrace magic.

OK, OK, I will move it.

> > In that case we should export task_detached().
>
> Or just recognize that this trivial wrapper around == -1 has little
> value two lines away from a place where = -1 is done explicitly.
> Really, the "abstraction" is more confusing than not in this function, IMHO.

Well, yes. The only problem it is not easy to grep for this check
without a helper.


(And I still hope we can change the rules sometimes, I think there
 is no good reason to have task_detached() or EXIT_DEAD tasks on
 ->children list. But this is offtopic.)

Oleg.


  reply	other threads:[~2009-02-05 22:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-29  4:29 [PATCH 3/4] ptrace: reintroduce __ptrace_detach() as a callee of ptrace_exit() Oleg Nesterov
2009-02-05  1:23 ` Roland McGrath
2009-02-05 14:39   ` Oleg Nesterov
2009-02-05 20:37     ` Roland McGrath
2009-02-05 22:06       ` Oleg Nesterov [this message]
2009-02-09  2:14         ` Roland McGrath

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=20090205220656.GA7660@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dvlasenk@redhat.com \
    --cc=jmarchan@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@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.