[RFC][PATCH 0/3] Procfs Task exe Symlinks

[Matt Helsley <matthltc@us.ibm.com>]

The kernel implements readlink of /proc/pid/exe by getting the file from the
first executable VMA. Then the path to the file is reconstructed and reported as
the result. While this method is often correct it does not always identify the
correct path.

I've described the problem in much greater detail in the first patch of this
series. 

Once case I had in mind while trying to solve this problem involves the use
of the out-of-tree MVFS filesystem. While that motivates my work on this patch
series I think there are issues with /proc/self/exe independent of MVFS and
which this patch series can solve. I've also explained the additional wrinkles
MVFS adds in the first patch.

One question that came up while solving this problem was trying to determine
what /proc/self/exe should point to. The common case is easy enough but does
not seem to unambiguously define /proc/self/exe in all possible cases. When
discussing the idea with Dave Hansen off-list I went through some possible
definitions such as:

"what's running"
"used to start"
"last exec"

For now I've chosen "last exec". I'd like to know if this doesn't fit with
what anyone would expect and/or if there's a better definition.

The first patch in this series attempts to solve the problem by keeping
an additional reference to the last exec'd file in the mm struct rather than
walking the VMA list for the first, executable, file-backed VMA.

The next patch adds a spinlock to protect the new reference rather than
reusing the mmap semaphore. This exists mainly to show where the mmap semaphore
is absolutely necessary and where there are other alternatives.

The last patch allows applications to change their exe symlink to fix the
case where a restart loader is designed to map the executable in rather than
use the exec system call.

If there are no objections to the direction of the patches I plan on making
the series acceptable for eventual inclusion.

Cheers,
	-Matt Helsley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/