On Sat, Oct 3, 2015 at 9:19 PM, Dominique Martinet <asmadeus@xxxxxxxxxxxxx> wrote: > 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. The solution depends on how 9p handles hard links. If any dentry will do then d_find_any_alias() will get you a dentry (any dentry) from the inode. Otherwise I know of no mechanism to get the backing dentry from the file. Thanks, Miklos -- 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
