Re: while_each_thread() under rcu_read_lock() is broken?
From: Paul E. McKenney
Date: Mon Jun 28 2010 - 19:44:09 EST
On Fri, Jun 25, 2010 at 11:55:48AM +0200, Oleg Nesterov wrote:
> On 06/24, Paul E. McKenney wrote:
> > On Thu, Jun 24, 2010 at 11:57:02PM +0200, Oleg Nesterov wrote:
> > > On 06/24, Paul E. McKenney wrote:
> > > >
> > > > 4. Some other thread might do pthread_exit(), removing itself
> > > > from the thread group, and again might do so while the hapless
> > > > reader is referencing that thread. In this case, we want
> > > > the hapless reader to continue scanning the remainder of the
> > > > thread group.
> > >
> > > Yes.
> > >
> > > But, if that thread was used as a starting point g, then
> > >
> > > before the patch: loop forever
> > > after the patch: break
> > So it is OK to skip some of the other threads in this case, even
> > though they were present throughout the whole procedure?
> I think, yes. We can miss them in any case, they can go away before
> while_each_thread(g, t) starts the scan.
> If g == group_leader (old or new), then we should notice this thread
> at least.
> Otherwise we can miss them all, with or without next_thread_careful().
Just to be sure that we are actually talking about the same scenario...
Suppose that a task group is lead by 2908 and has member 2909, 2910,
2911, and 2912. Suppose that 2910 does pthread_exit() just as some
other task is "ls"ing the relevant /proc entry. Is it really OK for
"ls" to show 2909 but not 2911 and 2912, even though 2911 and 2912
were alive and kicking the entire time?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/