linux-kernel - Re: [PATCH v4 6/7] ACPI/NUMA: Add log messages for memory ranges found in CEDT

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]

Date: Fri, 26 Apr 2024 20:14:48 +0200
From: Robert Richter <rrichter@....com>
To: Alison Schofield <alison.schofield@...el.com>
Cc: Dan Williams <dan.j.williams@...el.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-cxl@...r.kernel.org, Len Brown <lenb@...nel.org>
Subject: Re: [PATCH v4 6/7] ACPI/NUMA: Add log messages for memory ranges
 found in CEDT

On 25.04.24 11:56:44, Alison Schofield wrote:
> On Thu, Apr 25, 2024 at 09:30:15AM +0200, Robert Richter wrote:
> > On 24.04.24 10:54:22, Dan Williams wrote:
> > > Robert Richter wrote:
> > > > Adding a pr_info() when successfully adding a CFMWS memory range.
> > > > 
> > > > Suggested-by: Alison Schofield <alison.schofield@...el.com>
> > > > Signed-off-by: Robert Richter <rrichter@....com>
> > > > ---
> > > >  drivers/acpi/numa/srat.c | 10 +++++++++-
> > > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> > > > index e3f26e71637a..c62e4636e472 100644
> > > > --- a/drivers/acpi/numa/srat.c
> > > > +++ b/drivers/acpi/numa/srat.c
> > > > @@ -338,8 +338,11 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
> > > >  	 * found for any portion of the window to cover the entire
> > > >  	 * window.
> > > >  	 */
> > > > -	if (!numa_fill_memblks(start, end))
> > > > +	if (!numa_fill_memblks(start, end)) {
> > > > +		pr_info("CEDT: memblk extended [mem %#010Lx-%#010Lx]\n",
> > > > +			(unsigned long long) start, (unsigned long long) end - 1);
> > > 
> > > This looks like pr_debug() material to me.
> > 
> > This should have the same log level as the message below and/or its
> > corresponding SRAT message. CEDT mem blocks wouldn't be reported
> > otherwise only because a smaller (overlapping) entry was registered
> > before. That is why I used pr_info here.
> 
> It does feel like this message belongs but maybe it should also 
> mimic the SRAT define message and emit what node maps this range
> if memblocks were extended.
> 
> But...seems this will emit a message for every CFMWS range, even those
> where no memblk needed to be extended - ie the range was fully described
> in the SRAT.
> 
> Sadly, numa_fill_memblks() return of 'success' has double meaning.
> It can mean memblks were extended, or that (start, end) was found fully
> described. I don't see an good place to insert the message in
> numa_fill_memblks(). 
> 
> Sorry, just stirring the pot here, with no clear suggestion on how
> to emit info.

Ok, I have changed numa_fill_memblks() to also return if memblks have
been modified. That information is used to print the message.

> 
> > 
> > > 
> > > >  		return 0;
> > > > +	}
> > > >  
> > > >  	/* No SRAT description. Create a new node. */
> > > >  	node = acpi_map_pxm_to_node(*fake_pxm);
> > > > @@ -354,8 +357,13 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
> > > >  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
> > > >  			node, start, end);
> > > >  	}
> > > > +
> > > >  	node_set(node, numa_nodes_parsed);
> > > >  
> > > > +	pr_info("CEDT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
> > > > +		node, *fake_pxm,
> > > > +		(unsigned long long) start, (unsigned long long) end - 1);
> > > > +
> > > 
> > > This makes sense to mirror the SRAT pr_info().
> > 
> > I evaluated this.
> > 
> 
> I read Dan's comment as simple acceptance. Like, yeah this one is good
> because it mimics the SRAT pr_info.

Ah, I misread this, thanks for clarification.

-Robert