[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A14F781.6010103@kernel.org>
Date: Thu, 21 May 2009 15:41:05 +0900
From: Tejun Heo <tj@...nel.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...e.de>,
linux-kernel@...r.kernel.org,
Cornelia Huck <cornelia.huck@...ibm.com>,
linux-fsdevel@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...stanetworks.com>
Subject: Re: [PATCH 06/20] sysfs: Use dentry_ops instead of directly playing
with the dcache
Hello,
Eric W. Biederman wrote:
> Calling d_drop unconditionally when a sysfs_dirent is deleted has
> the potential to leak mounts, so instead implement dentry delete
> and revalidate operations that cause sysfs dentries to be removed
> at the appropriate time.
>
> Signed-off-by: Eric W. Biederman <ebiederm@...stanetworks.com>
Great, thanks for doing this. It's much better than the fragile vfs
tinkering sysfs has been doing.
> +static int sysfs_dentry_revalidate(struct dentry *dentry, struct nameidata *nd)
> +{
> + struct sysfs_dirent *sd = dentry->d_fsdata;
> + int is_dir;
> +
> + mutex_lock(&sysfs_mutex);
> +
> + /* The sysfs dirent has been deleted */
> + if (sd->s_flags & SYSFS_FLAG_REMOVED)
> + goto out_bad;
> +
> + mutex_unlock(&sysfs_mutex);
> +out_valid:
> + return 1;
> +out_bad:
> + /* Remove the dentry from the dcache hashes.
> + * If this is a deleted dentry we use d_drop instead of d_delete
> + * so sysfs doesn't need to cope with negative dentries.
> + */
> + is_dir = (sysfs_type(sd) == SYSFS_DIR);
> + mutex_unlock(&sysfs_mutex);
> + if (is_dir) {
> + /* If we have submounts we must allow the vfs caches
> + * to lie about the state of the filesystem to prevent
> + * leaks and other nasty things.
> + */
> + if (have_submounts(dentry))
> + goto out_valid;
> + shrink_dcache_parent(dentry);
> + }
> + d_drop(dentry);
> + return 0;
> +}
Ummm... what happens if sysfs recreates those identical nodes again
while the old dentries are lingering? The dead ones will linger till
the submounts are gone and then look ups after that will show the new
ones, right?
Thanks.
--
tejun
--
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