[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080130094801.GA143@tv-sign.ru>
Date: Wed, 30 Jan 2008 12:48:01 +0300
From: Oleg Nesterov <oleg@...sign.ru>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: paulmck@...ux.vnet.ibm.com,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Pavel Emelyanov <xemul@...nvz.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fix tasklist + find_pid() with CONFIG_PREEMPT_RCU
On 01/30, Eric W. Biederman wrote:
>
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists