linux-kernel - Re: [PATCH 07/32] x86/boot/e820: Print out sizes of E820 memory ranges

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aDtIqi9IL04233s9@gmail.com>
Date: Sat, 31 May 2025 20:21:30 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Andy Shevchenko <andy@...nel.org>
Cc: linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...nel.org>,
	Borislav Petkov <bp@...en8.de>, Juergen Gross <jgross@...e.com>,
	"H . Peter Anvin" <hpa@...or.com>,
	Kees Cook <keescook@...omium.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mike Rapoport <rppt@...nel.org>,
	Paul Menzel <pmenzel@...gen.mpg.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Woodhouse <dwmw@...zon.co.uk>
Subject: Re: [PATCH 07/32] x86/boot/e820: Print out sizes of E820 memory
 ranges

* Andy Shevchenko <andy@...nel.org> wrote:

> > Printing E820 maps with such details visualizes 'weird' ranges at a 
> > glance, and gives users a better understanding of how large the 
> > various ranges are, without having to perform hexadecimal 
> > subtraction in their minds.
> 
> Returning to the v1 discussion for sring_get_size(). Looking at its 
> code it seems to me that you haven't tried to use it. It should give 
> no .0 for the exact numbers. If it's not the case, please confirm 
> that we have a bug/feature. If it's documented (read: we have a test 
> case), then we would need an additional flag to avoid this behaviour 
> for your case. No need to reinvent a wheel here.

I briefly looked at get_string_size(), and it insists on the KiB/GiB 
sort of nonsense for base-2 sizes that we rarely use in x86 debug 
output, nor do we want to.

And I'm not convinced about 'struct range' and '%pre' either: I'd 
prefer to control both th data format and the output, while pra 
seems to insist both on using 'struct range', and on naming the
%output 'range', right?

I'm not convinced such a 'struct range' over-abstraction will actually 
simplify the code. The e820 debug printout code I extended in this 
series basically follows the data structure patterns and nomenclature 
of the e820 code itself.

It might or might not make sense to convert the e820 code to 'struct 
range' in a followup series, but that is beyond the scope of this 
series that refines the debug output.

Thanks,

	Ingo