lkml.org 
[lkml]   [2012]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 1/4] fs, proc: Introduce /proc/<pid>/task/<tid>/children entry v8
    On Mon, 23 Jan 2012 18:20:37 +0400
    Cyrill Gorcunov <gorcunov@openvz.org> wrote:

    > When we do checkpoint of a task we need to know the list of children
    > the task, has but there is no easy and fast way to generate reverse
    > parent->children chain from arbitrary <pid> (while a parent pid is
    > provided in "PPid" field of /proc/<pid>/status).
    >
    > So instead of walking over all pids in the system (creating one big process
    > tree in memory, just to figure out which children a task has) -- we add
    > explicit /proc/<pid>/task/<tid>/children entry, because the kernel already has
    > this kind of information but it is not yet exported.
    >
    > This is a first level children, not the whole process tree.
    >
    > v2:
    > - Kame suggested to use a separated /proc/<pid>/children entry
    > instead of poking /proc/<pid>/status
    > - Andew suggested to use rcu facility instead of locking
    > tasklist_lock
    > - Tejun pointed that non-seekable seq file might not be
    > enough for tasks with large number of children
    >
    > v3:
    > - To be on a safe side use %lu format for pid_t printing
    >
    > v4:
    > - New line get printed when sequence ends not at seq->stop,
    > a nit pointed by Tejun
    > - Documentation update
    > - tasklist_lock is back, Oleg pointed that ->children list
    > is actually not rcu-safe
    >
    > v5:
    > - Oleg suggested to make /proc/<pid>/task/<tid>/children
    > instead of global /proc/<pid>/children, which eliminates
    > hardness related to threads and children migration, and
    > allows patch to be a way simplier.
    >
    > v6:
    > - Drop ptrace_may_access tests, pids are can be found anyway
    > so nothing to protect here.
    > - Update comments and docs, pointed by Oleg.
    >
    > v7:
    > - Use get_pid over proc-pid directly, to simplify
    > code, pointed by Oleg.
    >
    > v8:
    > - Obtain a starting pid from the proc's inode directly.
    >
    > Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
    > Reviewed-by: Oleg Nesterov <oleg@redhat.com>
    > Cc: Andrew Morton <akpm@linux-foundation.org>
    > Cc: Pavel Emelyanov <xemul@parallels.com>
    > Cc: Serge Hallyn <serge.hallyn@canonical.com>
    > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

    From viewpoint I played with seq_file, yesterday.

    > +static void *children_seq_start(struct seq_file *seq, loff_t *pos)
    > +{
    > + return get_children_pid(seq->private, NULL, *pos);
    > +}
    > +
    > +static void *children_seq_next(struct seq_file *seq, void *v, loff_t *pos)
    > +{
    > + struct pid *pid = NULL;
    > +
    > + pid = get_children_pid(seq->private, v, *pos + 1);
    > + if (!pid)
    > + seq_printf(seq, "\n");
    > + put_pid(v);

    Because seq_printf() may fail. This seems dangeorus.

    If seq_printf() fails and returns NULL, "\n" will not be
    printed out and user land parser will go wrong.

    I think all seq_printf() should be handled in ->show().
    (And you can use seq_putc() for "\n".)

    Thanks,
    -Kame




    \
     
     \ /
      Last update: 2012-01-24 03:11    [W:0.028 / U:35.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site