lkml.org 
[lkml]   [2023]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] procfs: Fix /proc/self/maps output for 32-bit kernel and compat tasks
From

On 8/19/23 11:21, Helge Deller wrote:
> On a 32-bit kernel addresses should be shown with 8 hex digits, e.g.:
>
> root@debian:~# cat /proc/self/maps
> 00010000-00019000 r-xp 00000000 08:05 787324 /usr/bin/cat
> 00019000-0001a000 rwxp 00009000 08:05 787324 /usr/bin/cat
> 0001a000-0003b000 rwxp 00000000 00:00 0 [heap]
> f7551000-f770d000 r-xp 00000000 08:05 794765 /usr/lib/hppa-linux-gnu/libc.so.6
> f770d000-f770f000 r--p 001bc000 08:05 794765 /usr/lib/hppa-linux-gnu/libc.so.6
> f770f000-f7714000 rwxp 001be000 08:05 794765 /usr/lib/hppa-linux-gnu/libc.so.6
> f7d39000-f7d68000 r-xp 00000000 08:05 794759 /usr/lib/hppa-linux-gnu/ld.so.1
> f7d68000-f7d69000 r--p 0002f000 08:05 794759 /usr/lib/hppa-linux-gnu/ld.so.1
> f7d69000-f7d6d000 rwxp 00030000 08:05 794759 /usr/lib/hppa-linux-gnu/ld.so.1
> f7ea9000-f7eaa000 r-xp 00000000 00:00 0 [vdso]
> f8565000-f8587000 rwxp 00000000 00:00 0 [stack]
>
> But since commmit 0e3dc0191431 ("procfs: add seq_put_hex_ll to speed up
> /proc/pid/maps") even on native 32-bit kernels the output looks like this:
>
> root@debian:~# cat /proc/self/maps
> 0000000010000-0000000019000 r-xp 00000000 000000008:000000005 787324 /usr/bin/cat
> 0000000019000-000000001a000 rwxp 000000009000 000000008:000000005 787324 /usr/bin/cat
> 000000001a000-000000003b000 rwxp 00000000 00:00 0 [heap]
> 00000000f73d1000-00000000f758d000 r-xp 00000000 000000008:000000005 794765 /usr/lib/hppa-linux-gnu/libc.so.6
> 00000000f758d000-00000000f758f000 r--p 000000001bc000 000000008:000000005 794765 /usr/lib/hppa-linux-gnu/libc.so.6
> 00000000f758f000-00000000f7594000 rwxp 000000001be000 000000008:000000005 794765 /usr/lib/hppa-linux-gnu/libc.so.6
> 00000000f7af9000-00000000f7b28000 r-xp 00000000 000000008:000000005 794759 /usr/lib/hppa-linux-gnu/ld.so.1
> 00000000f7b28000-00000000f7b29000 r--p 000000002f000 000000008:000000005 794759 /usr/lib/hppa-linux-gnu/ld.so.1
> 00000000f7b29000-00000000f7b2d000 rwxp 0000000030000 000000008:000000005 794759 /usr/lib/hppa-linux-gnu/ld.so.1
> 00000000f7e0c000-00000000f7e0d000 r-xp 00000000 00:00 0 [vdso]
> 00000000f9061000-00000000f9083000 rwxp 00000000 00:00 0 [stack]
>
> This patch brings back the old default 8-hex digit output for
> 32-bit kernels and compat tasks.
>
> Signed-off-by: Helge Deller <deller@gmx.de>
> Fixes: 0e3dc0191431 ("procfs: add seq_put_hex_ll to speed up /proc/pid/maps")
> Cc: Andrei Vagin <avagin@openvz.org>
>
> diff --git a/fs/seq_file.c b/fs/seq_file.c
> index f5fdaf3b1572..1a15b531aede 100644
> --- a/fs/seq_file.c
> +++ b/fs/seq_file.c
> @@ -19,6 +19,7 @@
> #include <linux/printk.h>
> #include <linux/string_helpers.h>
> #include <linux/uio.h>
> +#include <linux/compat.h>
>
> #include <linux/uaccess.h>
> #include <asm/page.h>
> @@ -759,11 +760,16 @@ void seq_put_hex_ll(struct seq_file *m, const char *delimiter,
> seq_puts(m, delimiter);
> }
>
> +#ifdef CONFIG_64BIT
> /* If x is 0, the result of __builtin_clzll is undefined */
> - if (v == 0)
> + if (v == 0 || is_compat_task())
> len = 1;
> else
> len = (sizeof(v) * 8 - __builtin_clzll(v) + 3) / 4;
> +#else
> + /* On 32-bit kernel always use provided width */
> + len = 1;
> +#endif
>
> if (len < width)
> len = width;

Hi,

I think this is fixing the wrong thing.

seq_put_hex_ll() is a generic routine so the #ifdef/is_compat_task()
doesn't seem to belong there.

Moreover, the kerneldoc comment on this function states:

* seq_put_hex_ll(m, "", v, 8) is equal to seq_printf(m, "%08llx", v)

The seq_put_hex_ll() call from show_vma_header_prefix() is calling this
with the last argument (minimum padding length) being 8, so why is it
padding to more than that in the first place?

Look at your example:

> root@debian:~# cat /proc/self/maps
> 0000000010000-0000000019000 r-xp 00000000 000000008:000000005 787324
/usr/bin/cat

that's padded to... 13 hex characters? Huh?

Even on my x86_64, short addresses are only padded to 8 bytes, as they
should be in all cases. Could there possibly be a bug in parisc
__builtin_clzll()...?


Vegard

\
 
 \ /
  Last update: 2023-08-21 10:42    [W:0.067 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site