On Fri, 2007-07-13 at 03:07 +0100, Al Viro wrote:
> On Thu, Jul 12, 2007 at 07:00:12PM -0700, Matt Helsley wrote:
> > This patch avoids holding the mmap semaphore while walking VMAs in response
> > to
> > programs which read or follow the /proc/<pid|self>/exe symlink. This also
> > allows
> > us to merge mmu and nommu proc_exe_link() functions. The costs are holding
> > the
> > task lock, a separate reference to the executable file stored in the task
> > struct, and increased code in fork, exec, and exit paths.
>
> I don't think it's a food idea. Consider a program that deliberately
> creates an executable anon memory, copies the binary there, jumps there
> and unmaps the original. In the current tree you'll get nothing
> pinning the binary; with your patch it will remained busy.
Yes, it will prevent the filesystem with the executable file from being
unmounted. Do you have an example where the original filesystem urgently
needs to be unmounted while this unusual executable is running? Or is
umount -l sufficient here?
> It's not a common situation, of course, but there are legitimate uses
> for such technics...
Yes, I'm aware of at least one example where this technique has
legitimate uses: libhugetlbfs. I'm interested in testing others you may
be able to recommend as well.
Furthermore, in your example the VMA walk would make /proc/self/exe a
symlink to the file that backs the next executable VMA: libc, libdl,
etc. That seems rather odd to me. In contrast, with my
patch /proc/self/exe would always be a symlink to the original
executable.
Cheers,
-Matt Helsley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
