lkml.org 
[lkml]   [2018]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 14/39] ovl: stack file ops
Date
Al Viro:
> I'd managed to push that particular nest of horrors out of mind ;-/
> Having dug out my notes from back then and grepped around... The real
> mess is not even /proc/*/maps - it's /proc/*/map_files/* and yes, the
> reasons for that kludge are still valid ;-/
:::
> Uses of ->vm_file (and rules for those) are too convoluted to untangle
> at the moment. I still would love to get that straightened out, but
> it's not this cycle fodder, more's the pity...

I don't fully read this thread, but the discussion is related to the
file path printed in /proc/$$/maps? If so, as just for your
information, here is an approach that aufs took.

In linux-v2.6 era, aufs tried implementing mmap by customzing
address_space ops, but it was not good and failed completing the
implementation.
As wel as overlayfs, aufs has two struct file objects for a single
a regular file. One is for a virtual aufs' entry, and the other is for
a real layer's entry. When a user issues mmap(2) for the virtual file,
aufs redirects the request to the real file on the layer internally. So
the vm_file points to the real file. It means /proc/$$/maps prints the
unexpected file path.

Aufs added another struct file* vm_prfile in struct vma. It points to
the virtual aufs file, and /proc/$$/maps prints vm_prfile instead of
vm_file. Of cource, maintaining vm_prfile is important since vma may be
merged or splitted.
Still I don't like this approach, but I don't have another better idea,
also it works for many years. You can get the patch in
aufs4-standalone.git on sourceforge if you want.


J. R. Okajima

\
 
 \ /
  Last update: 2018-06-13 13:56    [W:0.152 / U:2.632 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site