On 07/26/2013 09:38 PM, Tejun Heo wrote:
Hello,
On Fri, Jul 26, 2013 at 05:59:00PM +0800, Dennis Chen wrote:
On 07/26/2013 05:49 PM, Dennis Chen wrote:
The patch is trying its best to avoid creating a dir under a parent dir which
is removing from
the system:
PATH0 (create a dir under 'PARENT/...') PATH1 (remove the
'PARENT/...')
sysfs_create_dir() { sysfs_remove_dir() {
... ...
if (kobj->parent)
spin_lock(&sysfs_assoc_lock);
parent_sd = kobj->parent->sd; <----- kobj->sd = NULL;
else
spin_unlock(&sysfs_assoc_lock);
parent_sd = &sysfs_root;
Suppose PATH1 enter the critical section first, then PATH0 begin to execute before
kobj->sd
has been reset to NULL, possibly PATH0 will get a non-NULL parent_sd since lack
of the
sysfs_assoc_lock protection in PATH0. In this case, PATH0 think it has a valid
parent_sd which
can be freed by PATH1 in the followed, refer to the comments in the patch.
Maybe we need
to figure out a perfect solution to solve the race condition, although the
codes in question are
in slow path...
I don't think sysfs is supposed to handle multiple actors trying to
populate and destroy the directory at the same time at all, so this
seems kinda moot. Do you have a case where this actually matters?
Thanks.
hello,Tejun. Nice. But seems I still have different opinion :). If you look at
the 'sysfs_do_create_link_sd()'
code, you will find a comment "target->sd can go away beneath us but is
protected with sysfs_assoc_lock.
Fetch target_sd from it", don't you think the sysfs_create_dir is the same as
the sysfs_do_create_link_sd()
essentially? if the answer is yes meaning the parent dir can go away when its
sub-dir is creating by sysfs_create_dir,
then the similar action should be taken as sysfs_create_link does. right?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
