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
"Jeffrey E. Hundstad" <[email protected]> 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
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
>
>
> 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;
_
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.