linux-kernel - Re: [PATCH 0/3] CXL updates for v6.19

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aRYLJmjBsggjzA99@rric.localdomain>
Date: Thu, 13 Nov 2025 17:45:26 +0100
From: Robert Richter <rrichter@....com>
To: Dave Jiang <dave.jiang@...el.com>
Cc: Alison Schofield <alison.schofield@...el.com>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Ira Weiny <ira.weiny@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Jonathan Cameron <jonathan.cameron@...wei.com>,
	Davidlohr Bueso <dave@...olabs.net>, linux-cxl@...r.kernel.org,
	linux-kernel@...r.kernel.org, Gregory Price <gourry@...rry.net>,
	"Fabio M. De Francesco" <fabio.m.de.francesco@...ux.intel.com>,
	Terry Bowman <terry.bowman@....com>,
	Joshua Hahn <joshua.hahnjy@...il.com>
Subject: Re: [PATCH 0/3] CXL updates for v6.19

On 13.11.25 08:20:59, Dave Jiang wrote:
> 
> 
> On 11/13/25 4:01 AM, Robert Richter wrote:
> > On 12.11.25 14:45:28, Dave Jiang wrote:
> >>
> >>
> >> On 11/12/25 1:51 PM, Robert Richter wrote:
> >>> Sending optional and rather independent patches from v5 of the CXL
> >>> address translation series [1] separately in this series. The patches
> >>> could be applied together with early pick up candidates from the
> >>> address translation series (namely patch #1 to #4 or #5).
> >>>
> >>> [1] https://patchwork.kernel.org/project/cxl/cover/20251112203143.1269944-1-rrichter@amd.com/
> >>>
> >>> Robert Richter (3):
> >>>   cxl: Simplify cxl_rd_ops allocation and handling
> >>>   cxl/acpi: Group xor arithmetric setup code in a single block
> >>>   cxl/region: Remove local variable @inc in cxl_port_setup_targets()
> >>>
> >>>  drivers/cxl/acpi.c        | 15 ++++-----------
> >>>  drivers/cxl/core/region.c | 25 +++++++------------------
> >>>  drivers/cxl/cxl.h         |  2 +-
> >>>  3 files changed, 12 insertions(+), 30 deletions(-)
> >>>
> >>
> >> Hi Robert, I'm having issues applying to 6.18-rc4.
> >>
> >> Applying: cxl: Simplify cxl_rd_ops allocation and handling
> >> Patch failed at 0001 cxl: Simplify cxl_rd_ops allocation and handling
> >> error: patch failed: drivers/cxl/core/region.c:2958
> >> error: drivers/cxl/core/region.c: patch does not apply
> > 
> > You need to apply it on cxl/next. There are conflicts otherwise.
> 
> Hi Robert,

> I actually need a series that cleanly applies to 6.18-rc4. I'll
> attempt to resolve the conflicts when I merge that branch to
> cxl/next. Of course a resolved public branch somewhere as guidance
> would be appreciated as well. Patches should not be based on
> cxl/next. Otherwise it gets really messy when I have to drop some
> changes due to issues.

This conflict resolution was not trivial as code was moved around and
then modified. It will be error prone and time consuming if someone
else does the conflict resolution.

In the cxl tree the conflict resolution is most of the time done in
merges which causes a headache when rebasing patches again on top of
each other or when forward-porting patches to that tree. The merges
basically hide the actual resolution and the patches that are involved
in the conflict. Recreation of trees with merges is also not trival.

Compared to conflict resolution when doing a (hopefully rare) rebase
of the cxl tree, it would be much cleaner if patches are on top of
each other. There are no conflicts once rebased and you don't carry
them around any longer. I don't see much benefit else. Also, the
author should resolve the conflicts who best knows the code.

If you prefer merges, how about this: Have separate branches as long
as there are no conflicts with mainline and merge them in. If there is
a conflict with one or more branches, base new patches on top of that
branch or create a merge point to port the patches on top of that.
That branch with the patches in can then be merged into mainline, but
there are no conflicts then.

> > 
> > Additionally, patch 3/3 (@inc variable change) of this series also
> > depends on patch 02/11 of v5 (store root decoder in in struct
> > cxl_region). If you chose to pickup some patches from v5 first on top
> > of cxl/next, then all this 3 patches should apply cleanly.
> > 
> > Since 02/11 is one of the first patches and it sounded to me some of
> > them will be applied as well, I would prefer that order to avoid
> > rebasing and resubmitting a v6 for that. Let me know if you want to
> > handle this differently.

> Hmmm....maybe I should just take the entire series hopefully next
> cycle when it's ready given all the dependencies?

Patches apply cleanly on top of each other, there is nothing that
blocks.

Let me know how to move forward.

Thanks,

-Robert