linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).