Vincent Bernat wrote on Sat, Oct 03, 2015: > Did you get any feedback on this? The problem is unfortunately still > present in 4.3-rc3. Sorry, haven't got any reply but I bet it is :( I've been meaning to ask again after a while but it slipped out of my head again... Basically 9P stores informations in both the inode and dentry, the change (4bacc9 "overlayfs: Make f_path always point to the overlay and f_inode to the underlay") makes it so that we get unexpected info in f_path->dentry->d_sb->s_fs_info and crash... I actually am not quite sure where the change needed belongs in the first place, I don't even know how the 9P layer could check if the filep isn't a "9p filep" in the first place, nor how it could work around it if it notices that's what happened, so I'm afraid I won't be of much help there... We probably can remove the need for dentry->d_sb->s_fs_info in this case (it's the 9p session info which we can get from the inode, which is also available) but 9p keeps a list with dentries for fids that I have no idea if it will make sense and/or be safe if we start mixing up overlay stuff in. Also, and worse, this only fixes the case where 9p is the underlay -- if someone gets the idea to use 9p as overlay then we'll get a "bad" inode and good dentry which will cause different problems, so once again we need to know where stuff comes from. And what about stacked overlays when 9P is in the middle, neither inode nor file would be "our's" ?... I'm sure I'm missing something simple and overcomplicating things, but I just don't have time to try to dig into the overlayfs code right now sorry. -- Dominique -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
