On 01/30, Eric W. Biederman wrote: > > "Paul E. McKenney" <[EMAIL PROTECTED]> writes: > > > On Tue, Jan 29, 2008 at 08:24:17PM -0700, Eric W. Biederman wrote: > >> > >> Using the tasklist_lock to still guarantee we see the list, the entire > >> list, and exactly the list for proper implementation of kill to > >> process groups and sessions still seems sane. > >> > >> So let's just remove the guarantee of find_pid being usable with > >> just the tasklist_lock held. > > > > Makes sense to me -- it is totally permissible to hold rcu_read_lock() > > across update code. ;-) > > Let me rephrase so it is clear. > > When dealing with pids there is exactly one case where we need > to take read_lock(&tasklist_lock);
Well, another example is sys_ioprio_set(IOPRIO_WHO_PGRP), > Posix (and sanely handling corner cases) requires that when we send a > signal to a process group or a session we have a snapshot in time view > of the entire group. In particular this allows us to send SIGKILL to > every member of the group and to have the entire group die. but you are right of course. tasklist pins group/session/->tasks. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
