Hello Arun,
Arun Chandran:
> 4) Now if I cd to /mnt/mnt and do 'ls' it hangs and I get the below oops.
>
>
> # dmesg
> [ 148.855382] ------------[ cut here ]------------
> [ 148.855382] kernel BUG at fs/aufs/sbinfo.c:336!
:::That is interesting. Smack enters aufs twice. Generally a systemcall enters VFS and then aufs. Once it enters aufs, aufs calls si_read_lock() which prohibits the branch manipulation (add/del branches in aufs) during the systemcall. Leaving aufs, si_read_unlock() is called and the branch manipulataion is allowed. Finally VFS and the systemcall return to the userspace. According to your stack trace, - lstat(2) is issued - VFS tries resolving the given path, and calls aufs_lookup(). - aufs finds the file (probably), and calls d_instatiate() which caches the filepath in memory. - d_instantiate() calls smack_d_instantiate(). obviously it should happen when smack is enabled only. - smack_d_instantiate() wants a specific XATTR set to that file and calls aufs_getxattr(). What a surprise! aufs_getxattr() should be called via systemcall as getxattr(2). The process should not re-enter aufs before completing aufs_lookup(). At least, aufs doesn't expect such behaviour. And aufs detects this "re-entering" behaviour and produces this message. If you had not enabled CONFIG_AUFS_DEBUG, the message would not be produced. But the behaviour would not be reliable anymore, I am afraid. It was good to enable CONFIG_AUFS_DEBUG. I don't know why smack people designed such behaviour. That is inetresting. At the same time, I think it ugly. Why didn't they create a hook at the very end of lookup, I wonder. Anyway here is a quick hack for you. Won't you test it? J. R. Okajima
a.patch.bz2
Description: BZip2 compressed data
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
