[Devel] Re: [PATCH 4/5] pid: use namespaced iteration on processes while sending signal to all

[Serge E. Hallyn]

Quoting Dave Hansen (dave at linux.vnet.ibm.com):
> On Thu, 2008-12-18 at 22:12 +0530, Gowrishankar M wrote:
> > At present we scan all processes in init namespace, whether in new namespace
> > or not, to send signal to all processes for container. Also we filter out
> > processes belonging to same namespace using task_pid_vnr().
> > 
> > Below patch proposes to use new macro controller to save time using pidmap.
> > In init namespace, this saving can be more or less achieved, as we check to
> > take every process with task_pid_vnr() otherwise.
> 
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > index 4530fc6..a2651bc 100644
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -1143,9 +1143,8 @@ static int kill_something_info(int sig, struct siginfo *info, pid_t pid)
> >  		int retval = 0, count = 0;
> >  		struct task_struct * p;
> > 
> > -		for_each_process(p) {
> > -			if (task_pid_vnr(p) > 1 &&
> > -					!same_thread_group(p, current)) {
> > +		for_each_process_in_ns(p, current->nsproxy->pid_ns) {
> > +			if (!same_thread_group(p, current)) {
> >  				int err = group_send_sig_info(sig, info, p);
> >  				++count;
> >  				if (err != -EPERM)
> 
> So this is a performance optimization?
> 
> Isn't that task_pid_vnr() basically an is_container_init() check?  Why
> did it go away?

Oh, good catch - the container init should still be skipped, no?

> This patch implies that ever process in another's thread group is also
> in the same pid namespace.  That seems like a sane assumption, but I'd
> probably hesitate without Oleg or Eric taking a good look.

copy_pid_ns() enforced that CLONE_THREAD and CLONE_NEWPID cannot
be specified together.

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