[Devel] Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.

Eric W. Biederman ebiederm at xmission.com
Tue Jul 31 00:59:38 PDT 2007


Tejun Heo <teheo at suse.de> writes:

> Eric W. Biederman wrote:
>> What do we use inode->i_mutex for?  I think we might be able
>> to kill that.
>> 
>> I'm starting to wonder if we can completely remove sysfs
>> from grabbing inode->i_mutex.
>
> i_mutex is grabbed when dentry and inode locking requires it.  It's not
> used to protect sysfs internal data structure anymore.  I don't think we
> can remove i_mutex grabbing without violating dentry/inode locking rules.

Not entirely no.  I think we can remove i_mutex from protecting dentry
tree modifications.

>>>> At first glance sysfs_assoc_lock looks just as bad.
>>> I think sysfs_assoc_lock is okay.  It's tricky tho.  Why do you think
>>> it's bad?
>> 
>> I'm still looking.  I just have a weird vibe so far.  sysfs_get_dentry
>> is really nasty with respect to locking.
>
> Yes, sysfs_get_dentry() is pretty hairy.  I wish I could use
> path_lookup() there but can't allocate memory for path name because
> looking up must succeed when it's called from removal path if dentry
> already exists.  Also, lookup_one_len_kern() bypasses security checks
> and there's no equivalent path_lookup() like function which does that.

We can use d_hash_and_lookup and that helps a lot.  I have attached
my in-progress rewrite of sysfs_get_dentry.  It's a little less
efficient but a whole lot easier to maintain.

> Locking rule aruond sysfs_assoc_lock is tricky.  It's mainly used to
> avoid race condition between sysfs_d_iput() vs. dentry creation, node
> removal, etc.  As long as sysfs_assoc_lock is held, sd->s_dentry can be
> dereferenced but you also need dcache_lock to determine whether the
> dentry is alive (dentry->d_inode != NULL) or in the process of being
> killed.  There were two or three race conditions around dentry
> reclamation in the past and several discussion threads about them.

I think I have figured out how to safely remove s_dentry entirely from
sysfs_dirent and that winds up removing a lot of subtle and nasty locking.
I'm hoping to have a good patch series after another couple of hours of
work.

struct dentry *__sysfs_get_dentry(struct sysfs_dirent *sd, int create)
{
	struct sysfs_dirent *cur;
	struct dentry *parent_dentry, *dentry;
	struct qstr name;
	struct inode *inode;

	parent_dentry = NULL;
	dentry = dget(sysfs_sb->s_root);

	do {
		/* Find the first ancestor I have not looked up */
		cur = sd;
		while (cur->s_parent != dentry->d_fsdata)
			cur = cur->s_parent;

		/* look it up */
		dput(parent_dentry);
		parent_dentry = dentry;
		name.name = cur->s_name;
		name.len = strlen(cur->s_name);
		dentry = d_hash_and_lookup(parent_dentry, &name);
		if (dentry)
			continue;
		if (!create)
			goto out;
		dentry = d_alloc(parent_dentry, &name);
		if (!dentry) {
			dentry = ERR_PTR(-ENOMEM);
			goto out;
		}
		inode = sysfs_get_inode(cur);
		if (!inode) {
			dput(dentry);
			dentry = ERR_PTR(-ENOMEM);
			goto out;
		}
		d_instantiate(dentry, inode);
		sysfs_attach_dentry(cur, dentry);
	} while (cur != sd);

out:	
	dput(parent_dentry);
	return dentry;
}

struct dentry *sysfs_get_dentry(struct sysfs_dirent *sd)
{
	struct dentry *dentry;

	mutex_lock(&sysfs_mutex);
	dentry = __sysfs_get_dentry(sd, 1);
	mutex_unlock(&sysfs_mutex);
	return dentry;
}

Eric
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list