[Unionfs] Fwd: unionfs_lower_dentry returns NULL

[Lucas C. Villa Real]

Hi Erez,

I've just tested this with UnionFS 2.2.4 in 2.6.24.3, and the problem
still persists. Do you have any pointers on this question?

Thanks,
Lucas


---------- Forwarded message ----------
From: Lucas C. Villa Real <lucasvr at gobolinux.org>
Date: Fri, Feb 22, 2008 at 12:53 AM
Subject: unionfs_lower_dentry returns NULL
To: unionfs at fsl.cs.sunysb.edu


Hello guys,

 I'm debugging a problem that appeared after an upgrade from UnionFS
 2.1.9 applied in a Linux 2.6.23.8 kernel to UnionFS 2.2.3 in a 2.6.24
 one. We at GoboLinux have a complement to the kernel named GoboHide,
 which allows one to hide dentries from userspace applications. The
 interface basically works through ioctls, where the dentry's inode
 number and the superblock which describes the mount point from a given
 path are stored in a list, which is later consulted at filldir, rmdir
 and unlink operations in the VFS. The inode number is taken right from
 userspace based on the information stored in the st_ino member in
 struct stat.

 Normal filesystems (ext2, reiserfs, jffs2, etc) doesn't require any
 special treatment: the inode numbers got from fstat() will match with
 the ones stored in their struct inode, and the comparison with the
 numbers stored in the gobohide list are straight forward. UnionFS,
 however, seems to store that in a different way -- the numbers read in
 fstat().st_ino are actually found in the UnionFS lower_dentry array.

 So far, the following code was being used to translate an inode number
 in GoboHide:

 ino_t gobolinux_translate_inode_nr(struct inode *inode)
 {
   ino_t ino = inode->i_ino;
 #ifdef CONFIG_UNION_FS
   if (inode->i_sb->s_op == &unionfs_sops) {
           /* we must take the inode number from the underlying filesystem */
           struct inode *lower_inode = unionfs_lower_inode(inode);
           ino = lower_inode->i_ino;
   }
 #endif
   return ino;
 }

 Since the switch to UnionFS 2.2.3, however, unionfs_lower_inode()
 returns NULL in some situations (vfs_rmdir). Since I'm not closed to
 UnionFS development, I'm not sure if this NULL pointer is coming from
 a bug or from a feature, so I'd really appreciate any pointers or
 suggestions in how to better handle with this situation.

 I'm attaching the GoboHide patch, just in case you want to test and
 reproduce the bug there. You'll also need a small userspace tool which
 can be downloaded from here:
 http://gobolinux.org/download/gobohide/GoboHide-0.13.tar.bz2

 The steps to reproduce are pretty simple:
 $ mount -t unionfs -o dirs=/some/dir=rw:/another/dir=ro none /mnt/unionfs
 $ cd /mnt/unionfs
 $ cp -a /path/to/some_directory .
 $ gobohide -h some_directory
 $ gobohide -l
 $ rm -rf some_directory

 At this point you should get an oops coming from the unexpected NULL
 pointer received from unionfs_lower_dentry (tested with a populated
 directory, but this shouldn't make a difference). The expected
 behavior would be to have some_directory removed from the filesystem
 tree and from the gobohide list (gobohide -l should not list it
 afterwards).

 Many thanks in advance, and once again thanks for your work on UnionFS!

 --
 Lucas
 powered by /dev/dsp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01-gobohide.patch
Type: application/octet-stream
Size: 20781 bytes
Desc: not available
Url : http://www.fsl.cs.sunysb.edu/pipermail/unionfs/attachments/20080310/8039dc81/01-gobohide-0001.obj