linux-kernel - Re: [PATCH] iomem: Adjust address width for 64-bit addresses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=wgszeWrJpC9oGwBo59CH+VdUXtjOpJ1QmnvtBgw4N4uJA@mail.gmail.com>
Date:   Sun, 14 May 2023 15:35:53 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Lingxiang Zheng <lxzheng@...il.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iomem: Adjust address width for 64-bit addresses

On Thu, May 11, 2023 at 9:28 AM Lingxiang Zheng <lxzheng@...il.com> wrote:
>
> Modify the address width determination in /proc/iomem output to better
> handle 64-bit addresses. The previous implementation did not correctly
> account for 64-bit address space, as it would limit the address width to 8
> hexadecimal characters.

Note that the width is the *minimum* number of characters to print
(with zero padding due to the zero in front in the printf format). Not
the maximum.

I do not believe we actually want to expand the width to be 16
characters wide, just because it's above the 4GB area. That would make
the numbers huge.

The main reason for the 4/8 split is actually for the IO port cases,
ie we do *not* want to show IO ports (that are limited to 16 bits) as
8 hex-char wide.

So think of the 4/8 as a visual distinction between the iomem and
ioports files.

And yes, I'm aware that some platforms have IO ports that are larger
than 16 bits, and on those platforms as a result the iomem and ioports
files will have similar visual behavior.

            Linus