[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090526213346.GA7073@redhat.com>
Date: Tue, 26 May 2009 23:33:47 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Roland McGrath <roland@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Christoph Hellwig <hch@...radead.org>,
Ingo Molnar <mingo@...e.hu>,
Pavel Emelyanov <xemul@...nvz.org>,
Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] ptrace: do_notify_parent_cldstop: fix the wrong
->nsproxy usage
On 05/26, Roland McGrath wrote:
>
> Acked-by: Roland McGrath <roland@...hat.com>
>
> Yes, all cases setting .si_pid should set it using the pid_ns of the
> recipient. Numerous other cases look wrong too, though maybe Sukadev has
> outstanding patches for those already? (It's been a while since we went
> around on this, and I am fuzzy on some of the details.) ptrace_notify,
> ptrace_signal,
Yes. Perhaps it would be nice to add a helper,
task_pid_xxx(struct task_struct child, struct task_struct *parent)
{
rcu_read_lock();
ret = task_pid_nr_ns(tsk, parent->nsproxy->pid_ns);
rcu_read_unlock();
return ret;
}
ptrace_notify/ptrace_signal can race with untrace + clear ->nsproxy,
probably we don't care.
> sys_kill, do_tkill all look wrong to me.
They should be fine, note the
if (from_ancestor_ns)
q->info.si_pid = 0;
in __send_signal(). If we send the signal "down" to the sub-namespace,
si_pid == 0 is correct. And, unlike do_notify_parent/ptrace_notify/etc
kill/tkill can't send the signal "up".
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists