From: Helge Deller <deller@gmx.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrei Vagin <avagin@openvz.org>,
linux-parisc <linux-parisc@vger.kernel.org>
Subject: Re: [PATCH v2] procfs: Fix /proc/self/maps output for 32-bit kernel and compat tasks
Date: Wed, 23 Aug 2023 00:04:54 +0200 [thread overview]
Message-ID: <a1a19e05-0cfd-cae5-9edb-9d63e70ee06d@gmx.de> (raw)
In-Reply-To: <8eb38faf-16a2-a538-b243-1b4706f73169@gmx.de>
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
next prev parent reply other threads:[~2023-08-22 22:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-22 9:20 [PATCH v2] procfs: Fix /proc/self/maps output for 32-bit kernel and compat tasks Helge Deller
2023-08-22 18:34 ` Andrew Morton
2023-08-22 20:53 ` Helge Deller
2023-08-22 22:04 ` Helge Deller [this message]
2023-08-23 10:14 ` Helge Deller
2023-08-25 21:09 ` Helge Deller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a1a19e05-0cfd-cae5-9edb-9d63e70ee06d@gmx.de \
--to=deller@gmx.de \
--cc=akpm@linux-foundation.org \
--cc=avagin@openvz.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).