This is just to vent.  

I was clearly not auditing patches well enough earlier and the above
patch got modified since the version I wrote initially.  Adding a
few addition is_init calls where what we care about test is not
is the real init process of the system (so we should treat it with
care) but is this the pid == 1 in my pid namespace.

So now we (or maybe me) are going to have to through all of those
is_init references and undo the changes for the ones that don't
apply to the global init.

Guys, please, please be more careful.

The one that set me off is the one in will_become_orphaned_pgrp.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Quoting Eric W. Biederman (ebiederm@xmission.com):
> 
> This is just to vent.  
> 
> I was clearly not auditing patches well enough earlier and the above
> patch got modified since the version I wrote initially.  Adding a
> few addition is_init calls where what we care about test is not
> is the real init process of the system (so we should treat it with
> care) but is this the pid == 1 in my pid namespace.
> 
> So now we (or maybe me) are going to have to through all of those
> is_init references and undo the changes for the ones that don't
> apply to the global init.
> 
> Guys, please, please be more careful.
> 
> The one that set me off is the one in will_become_orphaned_pgrp.
> 
> Eric

Yup.  Looks like ambiguous naming once again hid some real (future)
bugs.  This is of course safe so far in mainline,  but needs to be split
into

static inline int is_global_init(struct task_struct *tsk)
{
	return (tsk == &init_task);
}

and

static inline int
is_container_init(struct task_struct *task, struct pid_namespace *ns)
{
	return (__pid_nr(task, ns) == 1);
}

Where the latter is needed in, for instance, kernel/capability.c.

-serge
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Quoting Serge E. Hallyn (serue@us.ibm.com):
> Quoting Eric W. Biederman (ebiederm@xmission.com):
> > 
> > This is just to vent.  
> > 
> > I was clearly not auditing patches well enough earlier and the above
> > patch got modified since the version I wrote initially.  Adding a
> > few addition is_init calls where what we care about test is not
> > is the real init process of the system (so we should treat it with
> > care) but is this the pid == 1 in my pid namespace.
> > 
> > So now we (or maybe me) are going to have to through all of those
> > is_init references and undo the changes for the ones that don't
> > apply to the global init.
> > 
> > Guys, please, please be more careful.
> > 
> > The one that set me off is the one in will_become_orphaned_pgrp.
> > 
> > Eric

By the way thanks for catching this.  Clearly it slipped right past
the rest of us!

-serge

> Yup.  Looks like ambiguous naming once again hid some real (future)
> bugs.  This is of course safe so far in mainline,  but needs to be split
> into
> 
> static inline int is_global_init(struct task_struct *tsk)
> {
> 	return (tsk == &init_task);
> }
> 
> and
> 
> static inline int
> is_container_init(struct task_struct *task, struct pid_namespace *ns)
> {
> 	return (__pid_nr(task, ns) == 1);
> }
> 
> Where the latter is needed in, for instance, kernel/capability.c.
> 
> -serge
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers