linux-hardening - Re: [PATCH 18/26] mm/memblock: Add MEMBLOCK

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: <aVlsqdgXSBLIE9Xi@kernel.org>
Date: Sat, 3 Jan 2026 21:23:21 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Eugen Hristev <eugen.hristev@...aro.org>
Cc: linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, tglx@...utronix.de, andersson@...nel.org,
	pmladek@...e.com, rdunlap@...radead.org, corbet@....net,
	david@...hat.com, mhocko@...e.com, tudor.ambarus@...aro.org,
	mukesh.ojha@....qualcomm.com, linux-arm-kernel@...ts.infradead.org,
	linux-hardening@...r.kernel.org, jonechou@...gle.com,
	rostedt@...dmis.org, linux-doc@...r.kernel.org,
	devicetree@...r.kernel.org, linux-remoteproc@...r.kernel.org,
	linux-arch@...r.kernel.org, tony.luck@...el.com, kees@...nel.org
Subject: Re: [PATCH 18/26] mm/memblock: Add MEMBLOCK_INSPECT flag

On Sat, Jan 03, 2026 at 08:36:40AM +0200, Eugen Hristev wrote:
> 
> 
> On 12/29/25 08:56, Mike Rapoport wrote:
> > Hi Eugen,
> > 
> > On Wed, Nov 19, 2025 at 05:44:19PM +0200, Eugen Hristev wrote:
> >> This memblock flag indicates that a specific block is registered
> >> into an inspection table.
> >> The block can be marked for inspection using memblock_mark_inspect()
> >> and cleared with memblock_clear_inspect()
> > 
> > Can you explain why memblock should treat memory registered for inspection
> > differently?
> 
> It should not, at a first glance.
> 
> The purpose of the flag is to let memblock be aware of it.
> The flag is there to have a "memblock way" of registering the memory,
> which inside memblock , it can translate to a meminspect way of
> registering the memory. It's just an extra layer on top of meminspect.
> With this, it would be avoided to call meminspect all over the places it
> would be required, but rather use the memblock API.

memblock APIs are not available after boot on many architectures, most
notable being x86.

But regardless, I can't say I understand why using memblock APIs for
meminspect is better than using meminspect directly.
I'd imagine that using meminspect register APIs would actually make it more
consistent and it would be easier to identify what memory is registered
with meminspect.

In the end, memblock_alloc*() returns dynamically allocated memory, just
like kmalloc(), the difference is that memblock is active very early at
boot and disappears after core MM initialization.

> And further, inside memblock, it would be a single point where
> meminspect can be disabled (while preserving a no-op memblock flag), or
> easily changed to another API if needed.
> Ofcourse, one can call here directly the meminspect API if this is desired.
> Do you think it would be better to have it this way ?
> 
> Thanks for looking into it,
> Eugen

-- 
Sincerely yours,
Mike.