/proc/[0-9]*/maps where did the (deleted) status go?

/proc/[0-9]*/maps where did the (deleted) status go?

[Jeffrey E. Hundstad]

Hello,

In the 2.4.x kernels the /proc/[process id]/maps file contains that 
processes current mappings.  This is also true with 2.6.0-test9 but I've 
noticed a difference.  It is a feature I'll miss.  In the 2.4 kernels 
when a file is mapped but no longer exists (because it has been removed) 
the mapping line would contain the text "(deleted)" after it.

I've used this feature after I've updated libraries on my system.  I ran 
a little scriptlet (see below).  It'd tell me which processes were 
running with the old copy of the library.  This way I restart those 
processes.

Is this a feature that can be restored, or perhaps there's a better way 
to do it.  Let me know?


---- scriptlet library-restart-app follows:
#!/bin/bash
for i in `find /proc/ -mindepth 2 -maxdepth 2 -name "maps" | xargs grep 
-a deleted | grep -a -E -v /SYSV[0-9a-z]{8} |grep -a -v /dev/zero | cut 
-d ':' -f1 | cut -d '/' -f3 | sort | uniq | sed -e 
's/\(.*\)/\/proc\/\1\/cmdline/'`;do echo -n "`echo $i| cut -d '/' -f3` 
";cat $i|tr "\000" "\n" |head -1;done---- ---- scriptlet 
library-restart-app ends


-- 
jeffrey hundstad

Re: /proc/[0-9]*/maps where did the (deleted) status go?

[Andrew Morton]

"Jeffrey E. Hundstad" <jeffrey@hundstad.net> wrote:
>
> Hello,
> 
> In the 2.4.x kernels the /proc/[process id]/maps file contains that 
> processes current mappings.  This is also true with 2.6.0-test9 but I've 
> noticed a difference.  It is a feature I'll miss.  In the 2.4 kernels 
> when a file is mapped but no longer exists (because it has been removed) 
> the mapping line would contain the text "(deleted)" after it.
> 
> I've used this feature after I've updated libraries on my system.  I ran 
> a little scriptlet (see below).  It'd tell me which processes were 
> running with the old copy of the library.  This way I restart those 
> processes.
> 
> Is this a feature that can be restored, or perhaps there's a better way 
> to do it.  Let me know?

I see no difference between 2.4 and 2.6:


vmm:/home/akpm> uname -r
2.6.0-test9-mm2
vmm:/home/akpm> cat t.c
#include <sys/mman.h>
#include <fcntl.h>
#include <stdlib.h>

int main()
{
        int fd;
        char buf[4096];
        void *p;

        fd = open("foo", O_RDWR|O_CREAT, 0666);
        write(fd, buf, 4096);
        p = mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
        if (p == MAP_FAILED)
                perror("mmap");
        else
                sleep(1000);
}

vmm:/home/akpm> ./a.out&
[1] 1397
vmm:/home/akpm> cat /proc/$(pidof a.out)/maps
08048000-08049000 r-xp 00000000 03:02 1425796    /home/akpm/a.out
08049000-0804a000 rw-p 00000000 03:02 1425796    /home/akpm/a.out
40000000-40015000 r-xp 00000000 03:02 1406303    /lib/ld-2.3.2.so
40015000-40016000 rw-p 00014000 03:02 1406303    /lib/ld-2.3.2.so
40016000-40017000 rw-p 00000000 00:00 0 
40017000-40018000 rw-p 00000000 03:02 1425798    /home/akpm/foo
42000000-4212e000 r-xp 00000000 03:02 523311     /lib/tls/libc-2.3.2.so
4212e000-42131000 rw-p 0012e000 03:02 523311     /lib/tls/libc-2.3.2.so
42131000-42133000 rw-p 00000000 00:00 0 
bfffc000-c0000000 rwxp ffffd000 00:00 0 
vmm:/home/akpm> rm foo
vmm:/home/akpm> cat /proc/$(pidof a.out)/maps
08048000-08049000 r-xp 00000000 03:02 1425796    /home/akpm/a.out
08049000-0804a000 rw-p 00000000 03:02 1425796    /home/akpm/a.out
40000000-40015000 r-xp 00000000 03:02 1406303    /lib/ld-2.3.2.so
40015000-40016000 rw-p 00014000 03:02 1406303    /lib/ld-2.3.2.so
40016000-40017000 rw-p 00000000 00:00 0 
40017000-40018000 rw-p 00000000 03:02 1425798    /home/akpm/foo\040(deleted)
42000000-4212e000 r-xp 00000000 03:02 523311     /lib/tls/libc-2.3.2.so
4212e000-42131000 rw-p 0012e000 03:02 523311     /lib/tls/libc-2.3.2.so
42131000-42133000 rw-p 00000000 00:00 0 
bfffc000-c0000000 rwxp ffffd000 00:00 0 

Re: /proc/[0-9]*/maps where did the (deleted) status go?

[Jeffrey E. Hundstad]

I'm going to fine tune this report a little bit.  The behavior change is 
more subtle than I at first thought.

In 2.4: file that has been deleted, and is mapped will show as deleted 
in the maps file
In 2.6: file that has been deleted, and is mapped will show as deleted 
in the maps file

In 2.4: file that has been moved, and is mapped will show as deleted in 
the maps file
In 2.6: file that has been moved, and is mapped will show the new name 
in the maps file

While I don't see this as a bug in the kernel it certainly is a 
regression difference.  ...and I'd still like a way of tracking when the 
filename changes.  If anyone has a good suggestion let me know.

As a side note... this is the output of a file that has actually been 
deleted.  It looks different from the 2.4 version (note the "\040" is 
something new):

40018000-40019000 rw-s 00000000 03:04 13355559 
/home/j3gum/src/mmap/testfile.old\040(deleted)


Jeffrey E. Hundstad

Jeffrey E. Hundstad wrote:

> Hello,
>
> In the 2.4.x kernels the /proc/[process id]/maps file contains that 
> processes current mappings.  This is also true with 2.6.0-test9 but 
> I've noticed a difference.  It is a feature I'll miss.  In the 2.4 
> kernels when a file is mapped but no longer exists (because it has 
> been removed) the mapping line would contain the text "(deleted)" 
> after it.
>
> I've used this feature after I've updated libraries on my system.  I 
> ran a little scriptlet (see below).  It'd tell me which processes were 
> running with the old copy of the library.  This way I restart those 
> processes.
>
> Is this a feature that can be restored, or perhaps there's a better 
> way to do it.  Let me know?
>
>
> ---- scriptlet library-restart-app follows:
> #!/bin/bash
> for i in `find /proc/ -mindepth 2 -maxdepth 2 -name "maps" | xargs 
> grep -a deleted | grep -a -E -v /SYSV[0-9a-z]{8} |grep -a -v /dev/zero 
> | cut -d ':' -f1 | cut -d '/' -f3 | sort | uniq | sed -e 
> 's/\(.*\)/\/proc\/\1\/cmdline/'`;do echo -n "`echo $i| cut -d '/' -f3` 
> ";cat $i|tr "\000" "\n" |head -1;done---- ---- scriptlet 
> library-restart-app ends
>
>

Re: /proc/[0-9]*/maps where did the (deleted) status go?

[Andrew Morton]

> I'm going to fine tune this report a little bit.  The behavior change is 
> more subtle than I at first thought.
> 
> In 2.4: file that has been deleted, and is mapped will show as deleted 
> in the maps file
> In 2.6: file that has been deleted, and is mapped will show as deleted 
> in the maps file
> 
> In 2.4: file that has been moved, and is mapped will show as deleted in 
> the maps file
> In 2.6: file that has been moved, and is mapped will show the new name 
> in the maps file
> 
> While I don't see this as a bug in the kernel it certainly is a 
> regression difference.

OK, it's a bugfix.  The 2.6 behaviour is correct...

> ...and I'd still like a way of tracking when the 
> filename changes.

You could copy the file and remove the original.  That way it will show up
as (deleted).

> As a side note... this is the output of a file that has actually been 
> deleted.  It looks different from the 2.4 version (note the "\040" is 
> something new):
> 
> 40018000-40019000 rw-s 00000000 03:04 13355559 
> /home/j3gum/src/mmap/testfile.old\040(deleted)
> 

No, the \040 is present in current 2.4.  Urgh, but it's not there in
2.4.20.  We shouldn't have done that; we've gone and changed the format of
/proc/pid/maps in the stable kernel - your script will break on
2.4.23-pre9.


This patch (against 2.6) will restore the old 2.4 behaviour.  I'll scoot
the 2.4 equiv over to Marcelo.

diff -puN fs/proc/task_mmu.c~proc-pid-maps-output-fix fs/proc/task_mmu.c
--- 25/fs/proc/task_mmu.c~proc-pid-maps-output-fix	2003-11-02 00:38:26.000000000 -0800
+++ 25-akpm/fs/proc/task_mmu.c	2003-11-02 00:38:30.000000000 -0800
@@ -106,7 +106,7 @@ static int show_map(struct seq_file *m, 
 		if (len < 1)
 			len = 1;
 		seq_printf(m, "%*c", len, ' ');
-		seq_path(m, file->f_vfsmnt, file->f_dentry, " \t\n\\");
+		seq_path(m, file->f_vfsmnt, file->f_dentry, "");
 	}
 	seq_putc(m, '\n');
 	return 0;

_

Re: /proc/[0-9]*/maps where did the (deleted) status go?

[viro]

On Sun, Nov 02, 2003 at 12:47:39AM -0800, Andrew Morton wrote:
> This patch (against 2.6) will restore the old 2.4 behaviour.  I'll scoot
> the 2.4 equiv over to Marcelo.
> 
> diff -puN fs/proc/task_mmu.c~proc-pid-maps-output-fix fs/proc/task_mmu.c
> --- 25/fs/proc/task_mmu.c~proc-pid-maps-output-fix	2003-11-02 00:38:26.000000000 -0800
> +++ 25-akpm/fs/proc/task_mmu.c	2003-11-02 00:38:30.000000000 -0800
> @@ -106,7 +106,7 @@ static int show_map(struct seq_file *m, 
>  		if (len < 1)
>  			len = 1;
>  		seq_printf(m, "%*c", len, ' ');
> -		seq_path(m, file->f_vfsmnt, file->f_dentry, " \t\n\\");
> +		seq_path(m, file->f_vfsmnt, file->f_dentry, "");
>  	}
>  	seq_putc(m, '\n');
>  	return 0;

It's still wrong - the real bug is in seq_path(); the thing should *not*
try to escape anything in " (deleted)" part.