Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030222AbWCHWOM (ORCPT ); Wed, 8 Mar 2006 17:14:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030226AbWCHWOM (ORCPT ); Wed, 8 Mar 2006 17:14:12 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:63210 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S1030222AbWCHWOK (ORCPT ); Wed, 8 Mar 2006 17:14:10 -0500 To: Oleg Nesterov Cc: Andrew Morton , linux-kernel@vger.kernel.org, Ingo Molnar , "Paul E. McKenney" , Linus Torvalds Subject: Re: [PATCH rc5-mm] pids: kill PIDTYPE_TGID References: <440DEADB.72C3A8A6@tv-sign.ru> <440EED04.57FF5594@tv-sign.ru> <440F2F4A.3E91C272@tv-sign.ru> <440F50A7.EBAD87D5@tv-sign.ru> From: ebiederm@xmission.com (Eric W. Biederman) Date: Wed, 08 Mar 2006 15:12:59 -0700 In-Reply-To: <440F50A7.EBAD87D5@tv-sign.ru> (Oleg Nesterov's message of "Thu, 09 Mar 2006 00:46:15 +0300") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2407 Lines: 63 Oleg Nesterov writes: > Eric W. Biederman wrote: >> >> > p->group_leader = current->group_leader; >> > + list_add_tail_rcu(&p->thread_group, ¤t->thread_group); >> Can this be: >> list_add_tail_rcu(&p->thread_group, ¤t->group_leader->thread_group); > > Done. > >> That way at least the odds of missing a new task_struct when doing an >> rcu traversal are reduced almost to 0. > > Am I understand correctly? This change has effect when we are doing the > traversal starting from ->group_leader in a "best effort" manner lockless, > yes? Yes. The important point for reasoning about it is that we have a fixed point that we append or prepend to. I think I have finally figured out the invariants we will need to send signals using just the rcu_read_lock(). In that case we want to traverse the list in such a way that we are guaranteed to never see new entries. That gives us an atomic snapshot of the tasks to send signals to, and it gives us a progress guarantee. Now I need to look and see if any one has documented any rules regarding atomicity of sending signals to a group of processes. > [PATCH rc5-mm] pids: kill PIDTYPE_TGID > > depends on pidhash-dont-count-idle-threads.patch > > This patch kills PIDTYPE_TGID pid_type thus saving one hash table > in kernel/pid.c and speeding up subthreads create/destroy a bit. > It is also a preparation for the further tref/pids rework. > > This patch adds 'struct list_head thread_group' to 'struct task_struct' > instead. > > We don't detach group leader from PIDTYPE_PID namespace until another > thread inherits it's ->pid == ->tgid, so we are safe wrt premature > free_pidmap(->tgid) call. > > Currently there are no users of find_task_by_pid_type(PIDTYPE_TGID). > Should the need arise, we can use find_task_by_pid()->group_leader. > > include/linux/pid.h | 1 - > include/linux/sched.h | 11 ++++++++--- > kernel/exit.c | 10 +--------- > kernel/fork.c | 4 +++- > 4 files changed, 12 insertions(+), 14 deletions(-) > > Signed-off-by: Oleg Nesterov Acked-By: Eric Biederman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/