linux-kernel - Re: [PATCH] mm: memblock: avoid to create memmap for memblock nomap regions

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: <Zd2yyOuZNAUZgdac@kernel.org>
Date: Tue, 27 Feb 2024 12:00:40 +0200
From: Mike Rapoport <rppt@...nel.org>
To: "Aiqun Yu (Maria)" <quic_aiquny@...cinc.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
	Vijayanand Jitta <quic_vjitta@...cinc.com>, karahmed@...zon.de,
	qperret@...gle.com, robh@...nel.org, akpm@...ux-foundation.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	robh+dt@...nel.org, frowand.list@...il.com,
	devicetree@...r.kernel.org
Subject: Re: [PATCH] mm: memblock: avoid to create memmap for memblock nomap
 regions

On Tue, Feb 20, 2024 at 02:28:32PM +0800, Aiqun Yu (Maria) wrote:
> > > > > Hi Mike,
> > > > > 
> > > > > We've put effort on bootloader side to implement the similar suggestion of
> > > > > os bootloader to convey the reserved memory by omit the hole from
> > > > > /memory@...eg=[]} directly.
> > > > > While there is a concern from device tree spec perspective, link [1]: "A
> > > > > memory device node is required for all devicetrees and describes the
> > > > > physical memory layout for the system. "
> > > > > Do you have any idea on this pls?
> > > > 
> > > > I'm not sure I understand your concern. Isn't there a /memory node that
> > > > describes the memory available to Linux in your devicetree?
> > > 
> > > That was the question. It looks like your opinion on /memory was that
> > > it describes "memory available to Linux", while device tree spec
> > > defines it as "physical memory layout".
> > >
> > I suggested a workaround that will allow to save memory map for the
> > carveout.
> > The memory map is a run time description of the physical memory layout and
> > core mm relies on availability of struct page for every physical frame.
> > Having only partial memory map will lead to subtle bugs and crashes, so
> > it's not an option.
>
> Any idea of a formal solution for this case?
> It is a real use case for the commercial device. Memory saving is always a
> good topic for commercial devices. So for a total 128MB memory, ~60MB for
> kernel total available memory, and ~1M free memory saving is important from
> OEM point of view.
> 
> There are 3 types of memory:
> 1. used by firmware and not available to kernel at any time.
> Either struct page can be avoided by kernel. Or bootloader not pass this
> part of physical memory was discussed here.
> Any good ideas?

As I said, struct page must exist for all physical memory known to kernel.
If hiding the memory that is not available to kernel does not work for you
I don't have other ideas.

> 2. shared by firmware/subsystem, and can be read/write access by kernel.
> Just as it is now. Struct page can be allocated inside kernel and also
> reserved memory for this.
> 3. freely used by kernel.
> Just as it is now.



-- 
Sincerely yours,
Mike.