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

[Helge Deller <deller@gmx.de>]

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