Lou Gosselin: > I'm speculating here: my guess is that the VMM is pointing to a struct > inode which has been copied up by aufs into a new inode, but the VMM > continues to refer to the old one. The new and old struct inode continue > to share i_ino #. If this is the case, would it be possible to assign > the old inode struct a new unique i_ino? > > The rational being that the # should be unique per device, and the old > struct inode is never accessed using the old # anyways. (The old struct > is never accessed at all outside of mmap, which continues to use it's > pointer). The unique inode number would solve the current ambiguity.
Interesting. It will be difficult but worth to consider. In remount-phase, aufs may be able to unhash the cached dentries (inodes). If this unhashing is done in safe, then VFS will ignore the unhashed dentry and next lookup will not re-use the cached one. It means a new dentry/inode will be created (not shared) and a new inum will be assigned. There are many places in kernel to test whether a dentry is unhashed or not, I am afraid we (or only I) have to check all d_unhashed() calls. Also it will cost high since the unhashed dentry/inode are still in memory but they will not be re-used. > As an aside, was the decision to leave mmap files on their old branch > deliberate (maybe to keep executables working)? Or was it just how the > code played out? If the file was not mmapped, aufs "refresh"es the file on the succeeding access and detects the upper b/sh expectedly. By mmapping the file becomes a part of process address space, and aufs should not change it silently by refreshing. Otherwise, it can be a security hole or ap may abort. The decision was made explicitly and intentionally. J. R. Okajima ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
