[LTP/VFS] fcntl SETLEASE fails on ramfs/tmpfs

[Bryan Wu]

Hi folk,

This days I am digging into this LTP bug reported on our Blackfin test
machine, but I think it is general for other system.
https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3743

And I also found Kumar Gala reported this similar bug before.
http://lkml.org/lkml/2007/11/14/388

1, when opening and creating a new on ramfs/tmpfs, the dentry->d_count
will be added one as below:
--
ramfs_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
{
|_______struct inode * inode = ramfs_get_inode(dir->i_sb, mode, dev);
|_______int error = -ENOSPC;

|_______if (inode) {
|_______|_______if (dir->i_mode & S_ISGID) {
|_______|_______|_______inode->i_gid = dir->i_gid;
|_______|_______|_______if (S_ISDIR(mode))
|_______|_______|_______|_______inode->i_mode |= S_ISGID;
|_______|_______}
|_______|_______d_instantiate(dentry, inode);
|_______|_______dget(dentry);|__/* Extra count - pin the dentry in core */
|_______|_______error = 0;
|_______|_______dir->i_mtime = dir->i_ctime = CURRENT_TIME;
|_______}
|_______return error;
}
--
The dget(dentry) call introduces an extra count, why?
it is the same in tmpfs.

2, when calling  fcntl(fd, F_SETLEASE,F_WRLCK), it will return -EAGAIN
--
|_______if ((arg == F_WRLCK)
|_______    && ((atomic_read(&dentry->d_count) > 1)
|_______|_______|| (atomic_read(&inode->i_count) > 1)))
|_______|_______goto out;
--

because the dentry->d_count will be 2 not 1. I tested ext2 on Blackfin, it is 1.

3, so I guess maybe the dget(dentry) of ramfs_mknod is useless. But
after remove this dget(),
the ramfs can not be mounted as rootfs at all.

Is the bug in generic_setlease() or in the ramfs/tmpfs inode create function?

Of course, simply remove the test '((atomic_read(&dentry->d_count) >
1)' can workaround this issue.

Thanks
Best Regards,
-Bryan Wu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/