lkml.org 
[lkml]   [2008]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 3/3] Set si_pid to 0 for signals from ancestor namespace
On 11/12, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> > On 11/11, Sukadev Bhattiprolu wrote:
> >>
> >> +static void set_sigqueue_pid(struct sigqueue *q, struct task_struct *t,
> >> + struct pid *sender)
> >> +{
> >> + struct pid_namespace *ns;
> >> +
> >> + /* Set si_pid to the pid number of sender in the pid namespace of
> >> + * our destination task for all siginfo types that support it.
> >> + */
> >> + switch(q->info.si_code & __SI_MASK) {
> >> + /* siginfo without si_pid */
> >> + case __SI_TIMER:
> >> + case __SI_POLL:
> >> + case __SI_FAULT:
> >> + break;
> >> + /* siginfo with si_pid */
> >> + case __SI_KILL:
> >> + case __SI_CHLD:
> >> + case __SI_RT:
> >> + case __SI_MESGQ:
> >> + default:
> >> + /* si_pid for SI_KERNEL is always 0 */
> >> + if (q->info.si_code == SI_KERNEL || in_interrupt())
> >> + break;
> >> + /* Is current not the sending task? */
> >> + if (!sender)
> >> + sender = task_tgid(current);
> >> + ns = task_active_pid_ns(t);
> >> + q->info.si_pid = pid_nr_ns(sender, ns);
> >> + break;
> >> + }
> >> +}
> >
> > Why, why? Just: if from parent ns - clear .si_pid. No?
>
> We need the switch to know if we are a member of a union that supports
> si_pid.

Please look at http://marc.info/?l=linux-kernel&m=122634217518183

If SIG_FROM_USER is set, we know that .si_pid is "valid".

Yes, yes, yes. sys_rt_sigqueueinfo() is a problem, but in that
case we can't trust .si_code anyway.

> The in_interrupt thing is there simply because current is not
> useable from an interrrupt context, and there are some
> signals that get sent from an interrupt context.

Yes sure. But I don't think this check is enough, see other
emails. And this check is not needed once we have SIG_FROM_USER.

> Oh. As for the chunk that is:
> ns = task_active_pid_ns(t)
> q->info.si_pid = pid_nr_ns(sender, ns);
>
> If we are sending from a child to a parent namespace.

The notify_parent() case is fine, afaics (again I assume the "patch"
above which sets SIG_FROM_USER).

> The name of the
> child changes. There is some place F_SETSIG? sigfd? where we have
> something that resembles the full general case of processes being able
> to send a signal to any other process.

Yes, this needs attention too.

Oleg.



\
 
 \ /
  Last update: 2008-11-14 16:59    [W:0.716 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site