| Message ID | ZOR95DiR8tdcHDfq@p100 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] procfs: Fix /proc/self/maps output for 32-bit kernel and compat tasks | expand |
On Tue, 22 Aug 2023 11:20:36 +0200 Helge Deller <deller@gmx.de> 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. > > Fixes: 0e3dc0191431 ("procfs: add seq_put_hex_ll to speed up /proc/pid/maps") That was five years ago. Given there is some risk of breaking existing parsers, is it worth fixing this?
On 8/22/23 20:34, Andrew Morton wrote: > On Tue, 22 Aug 2023 11:20:36 +0200 Helge Deller <deller@gmx.de> 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. >> >> Fixes: 0e3dc0191431 ("procfs: add seq_put_hex_ll to speed up /proc/pid/maps") > > That was five years ago. Given there is some risk of breaking existing > parsers, is it worth fixing this? Huh... that's right! Nevertheless, kernel 6.1.45 has it right, which isn't 5 years old. I don't see the reason for that change right now, so I'll need to figure out what changed... Helge
On 8/22/23 22:53, Helge Deller wrote: > On 8/22/23 20:34, Andrew Morton wrote: >> On Tue, 22 Aug 2023 11:20:36 +0200 Helge Deller <deller@gmx.de> 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. >>> >>> Fixes: 0e3dc0191431 ("procfs: add seq_put_hex_ll to speed up /proc/pid/maps") >> >> That was five years ago. Given there is some risk of breaking existing >> parsers, is it worth fixing this? > > Huh... that's right! > Nevertheless, kernel 6.1.45 has it right, which isn't 5 years old. > I don't see the reason for that change right now, so I'll need to figure out what changed... It seems to be due to a new bug in gcc's __builtin_clzll() function (at least on parisc), which seems to return values for "long" (32bit) instead for "long long" (64bit). Please ignore this patch for now. Thanks! Helge
On 8/23/23 00:04, Helge Deller wrote: > On 8/22/23 22:53, Helge Deller wrote: >> On 8/22/23 20:34, Andrew Morton wrote: >>> On Tue, 22 Aug 2023 11:20:36 +0200 Helge Deller <deller@gmx.de> 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. >>>> >>>> Fixes: 0e3dc0191431 ("procfs: add seq_put_hex_ll to speed up /proc/pid/maps") >>> >>> That was five years ago. It's even worse :-) The real bug was introduced 10 years ago, in kernel 3.11. Commit 4df87bb7b6a22 ("lib: add weak clz/ctz functions") added __clzsi2() and __clzdi2() which operate on 32-bit parameters instead of 64-bit parameters (64-bit kernel is OK, just 32-bit kernels are affected!). This patch in my for-next tree fixes it: https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next&id=c8daddb96ddc4cc95b19944ef5dfa831d317fb4b I'll send the final patch to the mailing list if the tests via for-next seems ok. >> Given there is some risk of breaking existing parsers, is it worth fixing this? The parsers are not the problem, but Yes, we will have to fix it. The patch will not affect 64-bit kernels. But for 32-bit kernels we will need that patch to get __clzdi2() return the correct values, otherwise there might be other upcoming issues. Helge
On 8/23/23 00:04, Helge Deller wrote: > On 8/22/23 22:53, Helge Deller wrote: >> On 8/22/23 20:34, Andrew Morton wrote: >>> On Tue, 22 Aug 2023 11:20:36 +0200 Helge Deller <deller@gmx.de> 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. >>>> >>>> Fixes: 0e3dc0191431 ("procfs: add seq_put_hex_ll to speed up /proc/pid/maps") >>> >>> That was five years ago. Given there is some risk of breaking existing >>> parsers, is it worth fixing this? >> >> Huh... that's right! >> Nevertheless, kernel 6.1.45 has it right, which isn't 5 years old. >> I don't see the reason for that change right now, so I'll need to figure out what changed... > > It seems to be due to a new bug in gcc's __builtin_clzll() > function (at least on parisc), which seems to return values > for "long" (32bit) instead for "long long" (64bit). > > Please ignore this patch for now. To sum up: It was a bug in the in-kernel __clzdi2() function. This patch ("lib/clz_ctz.c: Fix __clzdi2() and __ctzdi2() for 32-bit kernels") fixes it: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=382d4cd1847517ffcb1800fd462b625db7b2ebea Thanks! Helge
diff --git a/fs/seq_file.c b/fs/seq_file.c index f5fdaf3b1572..52a0ea05cad2 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,8 +760,9 @@ void seq_put_hex_ll(struct seq_file *m, const char *delimiter, seq_puts(m, delimiter); } - /* If x is 0, the result of __builtin_clzll is undefined */ - if (v == 0) + /* If v is 0, the result of __builtin_clzll is undefined */ + /* Use provided width on 32-bit kernel and compat mode */ + if (v == 0 || !IS_ENABLED(CONFIG_64BIT) || in_compat_syscall()) len = 1; else len = (sizeof(v) * 8 - __builtin_clzll(v) + 3) / 4;
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. Fixes: 0e3dc0191431 ("procfs: add seq_put_hex_ll to speed up /proc/pid/maps") Cc: Andrei Vagin <avagin@openvz.org> Signed-off-by: Helge Deller <deller@gmx.de> --- v2: - Linux kernel test robot complained that is_compat_task() isn't known. Use in_compat_syscall() instead and check for 32-bit kernel with !IS_ENABLED(CONFIG_64BIT) ---