[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201011080704.GIH17609.SFVQLtJOOHFFMO@I-love.SAKURA.ne.jp>
Date: Mon, 8 Nov 2010 07:04:43 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: paulmck@...ux.vnet.ibm.com
Cc: sergey.senozhatsky@...il.com, viro@...iv.linux.org.uk,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, mingo@...e.hu
Subject: Re: [PATCH] rcu_read_lock/unlock protect find_task_by_vpid call
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.
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.
Regards.
--
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