Regarding bug 1243591 and aufs issue with file lifecycle
ben at decadent.org.uk
Thu Nov 14 04:50:11 UTC 2013
On Mon, 2013-11-04 at 16:49 +0000, Andy Whitcroft wrote:
> On Mon, Nov 04, 2013 at 02:51:24PM +0100, Wojciech Kocjan wrote:
> > Hi,
> > I have submitted a bug for Ubuntu that it does not apply the
> > aufs3-map.patch (the bug is here: https://bugs.launchpad.net/bugs/1243591).
> > Joseph Salisbury has recommended me to contact the mailing list to describe
> > the problem in more details.
> > I have originally been in contact with the aufs author and the discussion
> > related to the issue can be found here:
> > http://sourceforge.net/mailarchive/forum.php?thread_name=17716.1382529737%40jrobl&forum_name=aufs-users
> > The outcome of the discussion is that aufs was never fully tested without
> > the patch, and as an outcome of the discussion and subsequent checking,
> > aufs now requires applying the patch to work properly.
> > The patch itself can be found here:
> > http://sourceforge.net/p/aufs/aufs3-standalone/ci/aufs3.2/tree/aufs3-mmap.patch
> Gah that is a pretty nasty looking patch, affecting core vm structures
> (making them bigger). From what I can tell the underly bug is making
> /proc/$$/maps contains incorrect filenames? Is that right?
That was the original motivation.
> Which in
> your case makes a binary which carries its own .so inside itself and
> which pukes it out into a file for use, break, double gah.
This is not related to procfs, though; it is related to inode identity.
An inode normally stays around so long as it is referenced by a link or
a file descriptor or a memory mapping. However, mapping a file on aufs
results in a reference to an inode on one of the underlying filesystems.
dlopen() only keeps a memory mapping, not a file descriptor, so when the
first library is unlinked there are no references to its aufs inode and
it is freed. When the second library is created, its aufs inode may
have the same number as the first library had. dlopen() then finds that
the second library has the same device and inode numbers as the first,
and infers that it is the same file. It therefore returns a handle to
the first library again (and bumps its reference count).
aufs3-mmap.patch makes the mapping hold a reference to both the aufs
inode and the underlying filesystem inode.
> I personally would need to be convinced that there is no regression
> potential performance wise from this change at the very least before I
> could see it being acceptable. This is a bit of a specialist "use case"
> which is being affected.
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 828 bytes
Desc: This is a digitally signed message part
More information about the kernel-team