On Fri, 13 Nov 2009, Eric Paris wrote: > mount S ffff88001f86bd28 0 4126 4120 0x00000080 > mount S ffff88001f86bd28 0 4126 4120 0x00000080 > ffff88001f86bc38 0000000000000086 0000000000000011 ffff88001f86bc08 > 0000000000000700 0000000000000000 0000000000000013 ffffffff815884cd > ffff8800377532c8 000000000000f8e0 ffff8800377532c8 0000000000015600 > Call Trace: > [<ffffffffa01bec71>] fuse_get_req+0xb8/0x15b [fuse] > [<ffffffffa01bf359>] fuse_getxattr+0x58/0x14f [fuse] > [<ffffffff811b9ea2>] get_vfs_caps_from_disk+0x52/0xcd > [<ffffffff81093809>] audit_copy_inode+0x83/0xb1 > [<ffffffff81093d4f>] __audit_inode+0x1ee/0x1fd > [<ffffffff81104789>] audit_inode+0x28/0x2a > [<ffffffff811066b4>] do_path_lookup+0x63/0x8b > [<ffffffff81107c9c>] user_path_at+0x56/0x93 > [<ffffffff810ffaf0>] sys_readlinkat+0x2d/0x91 > [<ffffffff810ffb6f>] sys_readlink+0x1b/0x1d > [<ffffffff81011cf2>] system_call_fastpath+0x16/0x1b > > Userspace called readlink() and the audit system (after the vfs worked > out the path) needs to collect any fcaps. OK, this is a different problem than what I thought. Agreed, audit is not doing anything wrong here. The cause seems to be that fuse calls "mount -i -f ..." to add the filesystem entry to /etc/mtab. mount(8) then goes off and tries to canonicalize the path, calling readlink() on the mountpoint. Which is unnecessary, really. The path has already been canonicalized, but unfortunately there's no way currently to tell this to mount. In this light, the patch by Josef might be OK as a workaround, but I'll look at better ways to fix this. Josef, can you check whether the mtab is still correctly updated with your patch? Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
