Re: new command fexe

[Mark Wielaard <mark at klomp dot org>]

Hi Andrew,

On Wed, 2007-07-25 at 12:24 -0400, Andrew Cagney wrote:
> cagney@nettle$ cp /bin/bash /tmp
> cagney@nettle$ /tmp/bash
> cagney@nettle$ cp /bin/bash /tmp/a-very-long-file
> cagney@nettle$ mv !$ /tmp/bash
> mv /tmp/a-very-long-file /tmp/bash
> cagney@nettle$ /home/scratch/frysk/native/frysk-core/frysk/bindir/fexe $$
> null
> cagney@nettle$ /home/scratch/frysk/native/frysk-core/frysk/bindir/fexe -v $$
> 3905 null /tmp/bash4]setspeed (deleted)
> cagney@nettle$

Very interesting. It doesn't really depend on the something very-long,
just something with a longer path than the original. Also, it goes away
if in between any of these commands you actually examine /proc/$$/exe
first.

Looking at the kernel code I couldn't immediately find a fix, but it is
at least hinted at in fs/dcache.c that the result looks ugly for things
like open files in /proc that get deleted by a move. It also say "We
could be more polite about it, though." But I didn't see some simple
fix.

But this highlights the fact that it really is a fake symlink. Which you
cannot really trust at all except for displaying something human
readable as needed in the gui, but you shouldn't use it for trying to
get at the Elf image as done in the core, in that case you have to open
the original /proc/pid/exe directly. So we really need 2 interfaces here
to satisfy the 2 different ways getExe() is used. One to get the symlink
name to display and one to get at the file to open to get the actual exe
image (even when the original exe got moved or deleted).

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part