On Mon, Nov 08, 2010 at 12:28:17PM +0200, Sergey Senozhatsky wrote: > On (11/07/10 19:01), Paul E. McKenney wrote: > > On Mon, Nov 08, 2010 at 07:04:43AM +0900, Tetsuo Handa wrote: > > > Hello. > > > > > > Paul E. McKenney wrote: > > > > > Users missing rcu_read_lock() when calling find_task_by_vpid(): > > > > > > > > > > check_clock() in kernel/posix-cpu-timers.c > > > > > > > > This one has read_lock(&tasklist_lock). > > > > > > > Excuse me. Holding tasklist_lock lock does not help. > > > We must call rcu_read_lock() explicitly. > > > That's why 9728e5d6 "kernel/pid.c: update comment on find_task_by_pid_ns" was made. > > > > OK, good point, there are a few more kernels of unpopped corn here. > > > > Hello, > I prepared a patch for posix-cpu-timers. > > [PATCH] posix-cpu-timers: rcu_read_lock/unlock protect find_task_by_vpid call > Reviewed-by: Oleg Nesterov <oleg@xxxxxxxxxx> > > http://lkml.org/lkml/2010/11/3/257 Ah, very good, thank you!!! Thanx, Paul > Sergey > > > > > I think there are users who needlessly call read_lock(&tasklist_lock) > > > when they can use rcu_read_lock() instead. > > > But I don't know when to use read_lock(&tasklist_lock). > > > > > > If read_lock(&tasklist_lock) is needed only when we want to access > > > the "struct task_struct" after rcu_read_unlock(), maybe it is cleaner to > > > use a helper like > > > > > > struct task_struct *find_task_and_get(pid_t pid) > > > { > > > struct task_struct *task; > > > read_lock(&tasklist_lock); > > > rcu_read_lock(); > > > task = find_task_by_vpid(pid); > > > rcu_read_unlock(); > > > if (task) > > > get_task_struct(task); > > > read_unlock(&tasklist_lock); > > > return task; > > > } > > > > > > and hide tasklist_lock. > > > > This makes a lot of sense to me! That said, most of the current > > open-coded variants of your find_task_and_get() seem to have the > > rcu_read_unlock() after the get_task_struct() rather than before. But I > > don't claim to understand the locking design of this part of the kernel > > well enough to say which is the best approach. > > > > So, either way, will you be submitting the patches for this? > > > > Thanx, Paul > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
