linux-kernel - Re: [PATCH 1/6] dax/hmem, e820, resource: Defer Soft Reserved registration until hmem is ready

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: <68d587474b76c_10520100df@dwillia2-mobl4.notmuch>
Date: Thu, 25 Sep 2025 11:17:43 -0700
From: <dan.j.williams@...el.com>
To: "Koralahalli Channabasappa, Smita" <skoralah@....com>,
	<dan.j.williams@...el.com>, Smita Koralahalli
	<Smita.KoralahalliChannabasappa@....com>, <linux-cxl@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <nvdimm@...ts.linux.dev>,
	<linux-fsdevel@...r.kernel.org>, <linux-pm@...r.kernel.org>
CC: Davidlohr Bueso <dave@...olabs.net>, Jonathan Cameron
	<jonathan.cameron@...wei.com>, Dave Jiang <dave.jiang@...el.com>, "Alison
 Schofield" <alison.schofield@...el.com>, Vishal Verma
	<vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>, Matthew Wilcox
	<willy@...radead.org>, Jan Kara <jack@...e.cz>, "Rafael J . Wysocki"
	<rafael@...nel.org>, Len Brown <len.brown@...el.com>, Pavel Machek
	<pavel@...nel.org>, Li Ming <ming.li@...omail.com>, Jeff Johnson
	<jeff.johnson@....qualcomm.com>, Ying Huang <huang.ying.caritas@...il.com>,
	Yao Xingtao <yaoxt.fnst@...itsu.com>, Peter Zijlstra <peterz@...radead.org>,
	Greg KH <gregkh@...uxfoundation.org>, Nathan Fontenot
	<nathan.fontenot@....com>, Terry Bowman <terry.bowman@....com>, "Robert
 Richter" <rrichter@....com>, Benjamin Cheatham <benjamin.cheatham@....com>,
	PradeepVineshReddy Kodamati <PradeepVineshReddy.Kodamati@....com>, Zhijian Li
	<lizhijian@...itsu.com>, <ardb@...nel.org>, <bp@...en8.de>
Subject: Re: [PATCH 1/6] dax/hmem, e820, resource: Defer Soft Reserved
 registration until hmem is ready

Koralahalli Channabasappa, Smita wrote:
> On 9/8/2025 4:01 PM, dan.j.williams@...el.com wrote:
> > [ add Boris and Ard ]
> > 
> > Ard, Boris, can you have a look at the touches to early e820/x86 init
> > (insert_resource_late()) and give an ack (or nak). The general problem
> > here is conflicts between e820 memory resources and CXL subsystem memory
> > resources.
> > 
> > Smita Koralahalli wrote:
> >> Insert Soft Reserved memory into a dedicated soft_reserve_resource tree
> >> instead of the iomem_resource tree at boot.
> >>
> >> Publishing Soft Reserved ranges into iomem too early causes conflicts with
> >> CXL hotplug and region assembly failure, especially when Soft Reserved
> >> overlaps CXL regions.
> >>
> >> Re-inserting these ranges into iomem will be handled in follow-up patches,
> >> after ensuring CXL window publication ordering is stabilized and when the
> >> dax_hmem is ready to consume them.
> >>
> >> This avoids trimming or deleting resources later and provides a cleaner
> >> handoff between EFI-defined memory and CXL resource management.
> >>
> >> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
> > 
> > 
> >> Signed-off-by: Dan Williams <dan.j.williams@...el.com>
> > 
> > Smita, if you added changes this should have Co-developed-by. Otherwise
> > plain Signed-off-by is interpreted as only chain of custody.  Any other
> > patches that you add my Signed-off-by to should also have
> > Co-developed-by or be From: me.
> > 
> > Alternatively if you completely rewritel a patch with your own approach
> > then note the source (with a Link:) and leave off the original SOB.
> > 
> > Lastly, in this case it looks unmodified from what I wrote? Then it
> > should be:
> > 
> > From: Dan Williams <dan.j.williams@...el.com>
> > 
> > Signed-off-by: Dan Williams <dan.j.williams@...el.com>
> > Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
> > 
> > ...to show the chain of custody of you forwarding a diff authored
> > completely by someone else.
> 
> Thanks for clarifying, Dan. I wasn’t aware of the distinction before 
> (especially to handle the chain of custody..). I will update to reflect 
> that properly and will also be careful with how I handle authorship and 
> sign-offs in future submissions.

Yeah, the choice to replace From: is subjective and I usually reserve
that for significant rewrites. If any of the original patch remains then
add Co-developed-by + Signed-off-by. If none of the original patch
remains I do still like to say:

"based on an original patch by ..." with a Link: to that inspiration
patch.

...and if you just forward the original, keep From: untouched and just
add your own Signed-off-by as documented in
Documentation/process/submitting-patches.rst.