linux-kernel - Re: (2) (2) [RESEND PATCH 00/10] memblock: introduce memsize showing reserved memory

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]

Date: Sat, 1 Jun 2024 01:40:45 +0000
From: Wei Yang <richard.weiyang@...il.com>
To: Jaewon Kim <jaewon31.kim@...sung.com>
Cc: "richard.weiyang@...il.com" <richard.weiyang@...il.com>,
	Jaewon Kim <jaewon31.kim@...il.com>,
	Mike Rapoport <rppt@...nel.org>, "vbabka@...e.cz" <vbabka@...e.cz>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tkjos@...gle.com" <tkjos@...gle.com>,
	Pintu Agarwal <pintu.ping@...il.com>
Subject: Re: (2) (2) [RESEND PATCH 00/10] memblock: introduce memsize showing
 reserved memory

On Fri, May 31, 2024 at 05:21:41PM +0900, Jaewon Kim wrote:
>>On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote:
>>>>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote:
>>>>>(Sorry I might forget to change to be plain text)
>>>>>
>>>>>Oh good thing, I did not know this patch. Thanks.
>>>>>
>>>>>By the way, I've tried to get memblock/memory and kernel log from a
>>>>>device based on
>>>>>v6.6.17 kernel device, to see upstream patches above.
>>>>>memblok/memory does not show region for
>>>>
>>>>memblock/memory only shows ranges put in "memory".
>>>>memblock/reserved shows ranges put in "reserved".
>>>>
>>>>If we just put them in "reserved", it will not displayed in "memory".
>>>
>>>Hi
>>>Let me explain more.
>>>
>>>In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is.
>>>
>>># xxd -g 8 /proc/device-tree/memory/reg
>>>00000000: 0000000081960000 00000000000a0000  ................
>>>00000010: 0000000081a40000 00000000001c0000  ................
>>>
>>># cat sys/kernel/debug/memblock/memory
>>>   0: 0x0000000081960000..0x00000000819fffff    0 NONE
>>>   1: 0x0000000081a40000..0x0000000081bfffff    0 NONE
>>>
>>># cat sys/kernel/debug/memblock/reserved
>>>   0: 0x0000000082800000..0x00000000847fffff    0 NONE
>>>
>>>The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map.
>>>
>>>(I removed the name.)
>>><6>[    0.000000][    T0] OF: reserved mem: 0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable AAA
>>><6>[    0.000000][    T0] OF: reserved mem: 0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable BBB
>>><6>[    0.000000][    T0] OF: reserved mem: 0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable CCC
>>><6>[    0.000000][    T0] OF: reserved mem: 0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DDD
>>>
>>
>>This looks not printed by memblock_reserve(), right? It is printed by your own
>>driver?
>
>AFAIK these log came from the commit below.
>aeb9267eb6b1 of: reserved-mem: print out reserved-mem details during boot
>
>>
>>>So a smart parser should combine the krenel log and the memblock/memory log.
>>>
>>>In my memsize feature shows it like this though.
>>>
>>>0x0000000081400000-0x0000000081960000 0x00560000 (    5504 KB ) nomap unusable unknown
>>>
>>>BR
>>>
>>
>>I am sorry, I still not catch your point. Let me try to understand your message.
>>
>>You mentioned several regions, let me put them in order.
>>
>>(1)   0x0000000080000000..0x0000000080dfffff    printed by driver
>>(2)   0x0000000080e00000..0x00000000811fffff    printed by driver
>>(3)   0x0000000081200000..0x00000000813fffff    printed by driver
>>(4)   0x0000000081400000..0x0000000081960000    expected to print in new debugfs
>>(5)   0x0000000081960000..0x00000000819fffff    listed in reg/memory
>>(6)   0x0000000081a00000..0x0000000081a3ffff    printed by driver
>>(7)   0x0000000081a40000..0x0000000081bfffff    listed in reg/memory
>>(8)   0x0000000082800000..0x00000000847fffff    listed in reserved
>>
>>If you just want information for region (4), sound we can do it in user-space?
>>
>>BTW, are region 1, 2, 3, 6, reserved in membock?
>
>Yes correct, I though (4) case could be shown to easily catch these hidden regions.
>As I said, I think 1, 2, 3, 6 seem to be not passed to kernel, it was just tried as
>they are defined in kernel device tree.
>

As you mentioned above, 1, 2, 3, 6, is printed by "of" driver. And those
information is not shown in memblock/reserve.

I am afraid the proper way is to let memblock know those ranges. Sounds "of"
driver doesn't tell memblock about these.

>
>>
>>-- 
>>Wei Yang
>>Help you, Help me

-- 
Wei Yang
Help you, Help me