> > I just think that filesystem code should _never_ need to care about
> > mounts. If you want to do the lookup+open, you somehow will have to
> > deal with mounts, which is ugly.
>
> You appear to think that atomic lookup+open is a question of choice. It
> is not.
Atomic lookup+open is an optimization, and as such a question of
choice. Atomic create+open is not.
I know you are thinking of the non-exclusive create case when between
the lookup and the open the file is removed or transmuted on the
server.
Yes, it's tricky to sovle, but by no means impossible without atomic
lookup+open. E.g. consider this pseudo-code (only the atomic
open+create case) in open_namei():
down(&dir->d_inode->i_sem);
dentry = __lookup_hash(&nd->last, nd->dentry, nd);
do_last:
error = PTR_ERR(dentry);
if (IS_ERR(dentry)) {
up(&dir->d_inode->i_sem);
goto exit;
}
/* Negative dentry, just create the file */
if (!dentry->d_inode)
if (!IS_POSIXACL(dir->d_inode))
mode &= ~current->fs->umask;
vfs_create_open(...);
up(&dir->d_inode->i_sem);
dput(nd->dentry);
nd->dentry = dentry;
goto exit;
} else if (!(flag & O_EXCL) && may_create(dir)) {
if (__follow_mount(&path)) {
up(&dir->d_inode->i_sem);
goto mount_followed;
}
vfs_create_open(...);
up(&dir->d_inode->i_sem);
dput(nd->dentry);
nd->dentry = dentry;
goto exit;
}
/*
* It already exists.
*/
up(&dir->d_inode->i_sem);
error = -EEXIST;
if (flag & O_EXCL)
goto exit_dput;
if (__follow_mount(&path)) {
error = -ELOOP;
if (flag & O_NOFOLLOW)
goto exit_dput;
}
mount_followed:
Miklos
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
