Re: [PATCH v2] procfs: Fix /proc/self/maps output for 32-bit kernel and compat tasks

[Helge Deller]

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@xxxxxx> 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