>> diff --git a/fs/namespace.c b/fs/namespace.c
>> index 22e536705c45..6dc23614d44d 100644
>> --- a/fs/namespace.c
>> +++ b/fs/namespace.c
>> @@ -631,6 +631,41 @@ struct vfsmount *lookup_mnt(struct path *path)
>> return m;
>> }
>>
>> +/*
>> + * __is_local_mountpoint - Test to see if dentry is a mountpoint in the
>> + * current mount namespace.
>> + *
>> + * The common case is dentries are not mountpoints at all and that
>> + * test is handled inline. For the slow case when we are actually
>> + * dealing with a mountpoint of some kind, walk through all of the
>> + * mounts in the current mount namespace and test to see if the dentry
>> + * is a mountpoint.
>> + *
>> + * The mount_hashtable is not usable in the context because we
>> + * need to identify all mounts that may be in the current mount
>> + * namespace not just a mount that happens to have some specified
>> + * parent mount.
>> + */
>> +int __is_local_mountpoint(struct dentry *dentry)
>
> Minor nit: return value of any is_* function is either true or false, so why
> not
> declare it bool?
Because I am working on the core of the kernel and C compilers do weird
things with bool variables (storing them in bytes...). I expected a
type that the C compiler does not do weird things with would be more
readily received on a path whose performance people are interested in.
>> +{
>> + struct mnt_namespace *ns = current->nsproxy->mnt_ns;
>> + struct mount *mnt;
>> + int is_covered = 0;
>
> And the same for this var.
>
>> +
>> + if (!d_mountpoint(dentry))
>> + goto out;
>> +
>> + down_read(&namespace_sem);
>> + list_for_each_entry(mnt, &ns->list, mnt_list) {
>> + is_covered = (mnt->mnt_mountpoint == dentry);
>> + if (is_covered)
>> + break;
>> + }
>> + up_read(&namespace_sem);
>> +out:
>> + return is_covered;
>> +}
>> +
>> static struct mountpoint *new_mountpoint(struct dentry *dentry)
>> {
>> struct list_head *chain = mountpoint_hashtable + hash(NULL, dentry);
>> --
>> 1.7.5.4
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
