linux-kernel - Re: [PATCH v6 1/3] memory: implement memory_block_advise/probe_max

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZzQnvzPLsamSs7i4@PC2K9PVX.TheFacebook.com>
Date: Tue, 12 Nov 2024 23:14:55 -0500
From: Gregory Price <gourry@...rry.net>
To: Dan Williams <dan.j.williams@...el.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org, linux-mm@...ck.org,
	linux-cxl@...r.kernel.org, kernel-team@...a.com,
	Jonathan.Cameron@...wei.com, rrichter@....com, Terry.Bowman@....com,
	dave.jiang@...el.com, ira.weiny@...el.com,
	alison.schofield@...el.com, dave.hansen@...ux.intel.com,
	luto@...nel.org, peterz@...radead.org, tglx@...utronix.de,
	mingo@...hat.com, bp@...en8.de, hpa@...or.com, rafael@...nel.org,
	lenb@...nel.org, david@...hat.com, osalvador@...e.de,
	gregkh@...uxfoundation.org, akpm@...ux-foundation.org,
	rppt@...nel.org
Subject: Re: [PATCH v6 1/3] memory: implement
 memory_block_advise/probe_max_size

On Tue, Nov 12, 2024 at 01:28:03PM -0800, Dan Williams wrote:
> Gregory Price wrote:
> > Hotplug memory sources may have opinions on what the memblock size
> > should be - usually for alignment purposes.  For example, CXL memory
> > extents can be 256MB with a matching alignment. If this size/alignment
> > is smaller than the block size, it can result in stranded capacity.
> > 
> > Implement memory_block_advise_max_size for use prior to allocator init,
> > for software to advise the system on the max block size.
> > 
> > Implement memory_block_probe_max_size for use by arch init code to
> > calculate the best block size. Use of advice is architecture defined.
> > 
> > The probe value can never change after first probe. Calls to advise
> > after probe will return -EBUSY to aid debugging.
> > 
> > On systems without hotplug, always return -ENODEV and 0 respectively.
> 
> Should the advice just succeed when the result does not matter?
> 

I figure at some point during __init the value will be probed and subsequent
calls will be ignored. I'd rather fail explicitly in that case to assist
debugging - otherwise it might be a little maddening to discover your callsite
is too late in the process.

> Otherwise, it depends on the caller to not care based on config.
> 
> I do not feel that strongly about it, so either way:
> 
> Acked-by: Dan Williams <dan.j.williams@...el.com>