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: <20240521025329epcms1p6ce11064c0f0608a0156d82fda7ef285c@epcms1p6>
Date: Tue, 21 May 2024 11:53:29 +0900
From: Jaewon Kim <jaewon31.kim@...sung.com>
To: Jaewon Kim <jaewon31.kim@...sung.com>, "rppt@...nel.org"
	<rppt@...nel.org>, "vbabka@...e.cz" <vbabka@...e.cz>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jaewon31.kim@...il.com" <jaewon31.kim@...il.com>, "tkjos@...gle.com"
	<tkjos@...gle.com>
Subject: RE: [RESEND PATCH 00/10] memblock: introduce memsize showing
 reserved memory

>--------- Original Message ---------
>Sender : 김재원 <jaewon31.kim@...sung.com>System Performance Lab.(MX)/삼성전자
>Date   : 2024-05-21 11:40 (GMT+9)
>Title  : [RESEND PATCH 00/10] memblock: introduce memsize showing reserved memory
>?
>Some of memory regions can be reserved for a specific purpose. They are
>usually defined through reserved-memory in device tree. If only size
>without address is specified in device tree, the address of the region
>will be determined at boot time.
>
>We may find the address of the memory regions through booting log, but
>it does not show all. And it could be hard to catch the very beginning
>log. The memblock_dump_all shows all memblock status but it does not
>show region name and its information is difficult to summarize.
>
>This patch introduce a debugfs node, memblock/memsize, to see reserved
>memory easily.
>
>Here's an example
>
>$ cat debugfs/memblock/memsize
>
>0x0000000000000000-0x0000000000000000 0x02000000 (?  32768 KB )?  map reusable linux,cma
>0x0000000000000000-0x0000000000000000 0x01000000 (?  16384 KB )?  map reusable vxxxxx
>...
>0x0000000000000000-0x0000000000000000 0x004e0000 (? ? 4992 KB ) nomap unusable unknown
>0x0000000000000000-0x0000000000000000 0x00400000 (? ? 4096 KB ) nomap unusable cxxxxx
>0x0000000000000000-0x0000000000000000 0x00e00000 (?  14336 KB ) nomap unusable gxxxxx
>
>Reserved? ? : 1223856 KB
> .kernel? ? :? 275208 KB
>? .text? ?  :?  16576 KB
>? .rwdata?  :? ? 1963 KB
>? .rodata?  :?  11920 KB
>? .bss? ? ? :? ? 2450 KB
>? .memmap?  :? 186368 KB
>? .etc? ? ? :?  55933 KB
> .unusable? :? 948648 KB
>System? ? ? : 11359056 KB
> .common? ? : 10306384 KB
> .reusable? : 1052672 KB
>Total? ? ?  : 12582912 KB ( 12288.00 MB )
>
>Jaewon Kim (10):
>? memblock: introduce memsize showing reserved memory
>? memblock: detect hidden memory hole size
>? memblock: handle overlapped reserved memory region
>? memblock: take a region intersecting an unknown region
>? memblock: track memblock changed at early param
>? memblock: recognize late freed size by checking PageReserved
>? memblock: track kernel size on memsize
>? memblock: print memsize summary information
>? memblock: print kernel internal size
>? memblock: support memsize reusable to consider as reusable
>
> drivers/of/fdt.c? ? ? ? ? ?  |? 11 +
> drivers/of/of_reserved_mem.c |? 12 +-
> include/linux/memblock.h? ?  |? 29 ++
> init/main.c? ? ? ? ? ? ? ? ? |? 13 +-
> kernel/dma/contiguous.c? ? ? |?  9 +-
> mm/Kconfig? ? ? ? ? ? ? ? ?  |? 16 ++
> mm/memblock.c? ? ? ? ? ? ? ? | 502 ++++++++++++++++++++++++++++++++++-
> mm/mm_init.c? ? ? ? ? ? ? ?  |?  6 +-
> mm/page_allocc? ? ? ? ? ? ? |? 10 +-
> 9 files changed, 597 insertions(+), 11 deletions(-)
>
>-- 
>2.25.1

Hello Mike 

This is actually RESEND as it was introduced 2 years ago.
Please refer to https://lore.kernel.org/linux-mm/YkQB6Ah603yPR3qf@kernel.org/#t

> But you never provided details about *why* you want this information exposed.

For your question, I'd like to say ;
We can see the same format and exact information between different version of kernel status.

1) Internally we can check if the reserved memory changes.
2) Externally we can communicate between chipset vendors and OEM, with a same format.

This helps us to communitcate well, to easily detect changes or just to see differences.

Jaewon Kim


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ