Re: /proc/[0-9]*/maps where did the (deleted) status go?
From: Andrew Morton
Date: Sun Nov 02 2003 - 03:48:54 EST
> 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;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/