Re: [PATCH 2/2] cgroup: fix cgroup_path() vs rename() race, take 2

[Al Viro]

On Sun, Feb 17, 2013 at 12:03:37PM +0800, Li Zefan wrote:
> rename() will change dentry->d_name. The result of this race can
> be worse than seeing partially rewritten name, but we might access
> a stale pointer because rename() will re-allocate memory to hold
> a longer name.
> 
> As accessing dentry->name must be protected by dentry->d_lock or
> parent inode's i_mutex, while on the other hand cgroup-path() can
> be called with some irq-safe spinlocks held, we can't generate
> cgroup path using dentry->d_name.
> 
> Alternatively we make a copy of dentry->d_lock and save it in
> cgrp->name when a cgroup is created, and update cgrp->name at
> rename().

Yecchhh...  This is just plain wrong.  If nothing else, your locking
is way too heavy for your uses.  Just put freeing those separately
allocated names in RCU callback and assign them on rename with
rcu_assign_pointer().  Then put cgroup_path() under rcu_read_lock()
(most of the callers already are) and be done with that.
--
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/