All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] proc: Expose /proc/<pid>/task/<tid>/children unconditionally
Date: Wed, 26 Jun 2013 17:57:28 +0200	[thread overview]
Message-ID: <20130626155728.GA2141@redhat.com> (raw)
In-Reply-To: <CALCETrV2WZ3m82D4THfxvmASW8AOf1SN7Pu14vE0jMORupO5xw@mail.gmail.com>

On 06/25, Andy Lutomirski wrote:
>
> On Tue, Jun 25, 2013 at 2:52 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> > On Tue, Jun 25, 2013 at 02:36:31PM -0700, Andy Lutomirski wrote:
> >> On Tue, Jun 25, 2013 at 1:17 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> >> > On 06/26, Cyrill Gorcunov wrote:
> >> >>
> >> >> On Tue, Jun 25, 2013 at 12:51:45PM -0700, Andy Lutomirski wrote:
> >> >> > This is currently only available if CONFIG_CHECKPOINT_RESTORE, which
> >> >> > is hidden under CONFIG_EXPERT.  It's generally useful functionality,
> >> >> > though, so expose it unconditionally.
> >> >> >
> >> >> > Cc: Cyrill Gorcunov <gorcunov@openvz.org>
> >> >> > Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> >> >> Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
> >> >
> >> > I didn't see the patch but I guess it is trivial and I agree with intent ;)
> >>
> >> The patch works, but "children" is only listed under task/<tid>, not
> >> under /proc/<pid>.  Is that intentional?  Fixing it would be a
> >> one-liner.
> >
> > Yeah, it's intentional. Here some explanations from Oleg (check out
> > the whole thread, it's not that big https://lkml.org/lkml/2011/12/9/220)
> > in short this might require some more code, but i'll re-check tomorrow.
>
> This is a little strange.  It looks like ppid (in status) shows the
> tgid,

Yes,

> but the actual real_parent can refer to a thread (as opposed to
> a thread group leader),

Yes.

This is mostly the internal implementation detail. And probably it
would be nice to move ->children from task_struct to signal_struct.

However. See __WNOTHREAD in man waitpid. I think this is the only
(historical) reason. Otherwise the real_parent's tid doesn't matter,
the parent is always the whole process, not sub-thread.

> and task/tid/children respects that.

Well, it should respect if you want to restart and keep __WNOTHREAD
working.

But there is another reason. It is not trivial to list all children
under /proc/<pid>, and the fix would not be a one-liner ;) You need
to fight with the exiting sub-threads and reparenting. 

> So the
> tree that you get by following task/tid/ children won't be quite the
> same as the tree you get by following ppid.

Not sure I understand... but in any case, yes you need to read
/proc/pid/task/*/children to construct the tree.

> I wonder if the ptid should be added to status.  Is there anything
> (other than task/tid/children)

Perhaps, I dunno.

Better yet, we should kill __WNOTHREAD ;) I am wondering if it is still
used.

Oleg.


  parent reply	other threads:[~2013-06-26 16:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-25 19:51 [PATCH] proc: Expose /proc/<pid>/task/<tid>/children unconditionally Andy Lutomirski
2013-06-25 20:16 ` Cyrill Gorcunov
2013-06-25 20:17   ` Oleg Nesterov
2013-06-25 21:36     ` Andy Lutomirski
2013-06-25 21:52       ` Cyrill Gorcunov
2013-06-25 22:01         ` Andy Lutomirski
2013-06-26  7:21           ` Cyrill Gorcunov
2013-06-26 15:57           ` Oleg Nesterov [this message]
2013-06-26 16:14             ` Andy Lutomirski
2013-06-26 21:05             ` [PATCH] proc: Document that /proc/<pid>/task/<tid>/children really is per-thread Andy Lutomirski
2013-06-27  6:21               ` Cyrill Gorcunov
2013-07-01 16:49               ` Rob Landley
2013-07-01 17:36                 ` Andy Lutomirski

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=20130626155728.GA2141@redhat.com \
    --to=oleg@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    /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.