Re: [PATCH] rcu_read_lock/unlock protect find_task_by_vpid call

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux