Re: [PATCH 0/8] cxl: Assorted fixes

On Wed, Aug 12, 2026 at 10:10:35AM +0800, Guixin Liu wrote:
> 
> 
> 在 2026/8/12 03:57, Alison Schofield 写道:
> > On Tue, Aug 11, 2026 at 07:36:00PM +0800, Guixin Liu wrote:
> > > This is a batch of fixes found while auditing drivers/cxl. They are
> > > independent of each other and can be applied individually or dropped in
> > > any combination; they are only sent together because they came out of the
> > > same pass over the code.
> > Hi Guixin Liu.
> > 
> > Thanks for taking a look at CXL and putting these fixes together. I
> > appreciate that the intent here is to make the individual fixes easy to
> > take or drop. From the maintainer side, though, a grab bag of independent
> > findings from an audit has somewhat the opposite effect. It leaves us
> > with the audit results and the homework. :)
> > 
> > We have been working through this kind of cleanup in focused functional
> > areas, like features, HDM enumeration, etc. Please take a similar approach
> > rather than collecting unrelated findings into a single series. Address
> > one area at a time.
> Sorry, this is my first time sending patch to cxl mailing list,
> I will pay attention to these next time, thanks.
> > 
> > As part of that work, please check mailing list traffic and cxl/next for
> > fixes that have already been posted or merged, and review the pre-existing
> > complaints reported by the Sashiko bot against your patchset:
> > https://sashiko.dev/#/patchset/20260811113608.2815625-1-kanie%40linux.alibaba.com
> Sure, I will check before,
> 
> but why dosen't Sashiko reply directly in the current email? I can't reply
> Sashiko.
> > Please also follow the conventions we use for fix commit messages. They
> > should not narrate the code change, but rather describe what happens today,
> > why that is wrong and its impact, then state how the patch fixes it.
> > For an example of switching from code narration to behavior description,
> > take a look at my recent reply to a commit message w similar issue:
> > https://lore.kernel.org/linux-cxl/[email protected]/
> Got that, thanks.
> 
> Best Regards,
> Guixin Liu

Hi Guixin,

I think some of your fixes are already addressed.
For what I've known, the first 2 patches are already covered in my patch series

https://lore.kernel.org/linux-cxl/[email protected]/

Best regards,
Richard Cheng.


> > This up-front triage is becoming increasingly important as we see more
> > AI-assisted audits and fix submissions. Without it, maintainers end up
> > determining whether each finding is still present, already being
> > addressed, significant enough to fix, and where it fits with ongoing
> > work. That review burden does not scale with the volume of AI-generated
> > findings.
> > 
> > Rather than reworking this series as a whole, please apply this feedback
> > to focused CXL fixes you submit going forward.
> > 
> > Thanks,
> > Alison
> > 
> > > Guixin Liu (8):
> > >    cxl/features: Validate the fwctl RPC input length
> > >    cxl/features: Bound the Get Feature output by the user output buffer
> > >    cxl/core: Fix dport use-after-free via the einj_inject debugfs file
> > >    cxl/pci: Fix NULL pointer dereference in reset detection
> > >    cxl/hdm: Fix out of bounds read of the decoder target list
> > >    cxl/cdat: Fix uninitialized stack use in endpoint bandwidth gathering
> > >    cxl/mce: Validate the memdev and endpoint before use
> > >    cxl/region: Unregister the pmem region bridge on setup failure
> > > 
> > >   drivers/cxl/core/cdat.c        |  6 +++---
> > >   drivers/cxl/core/features.c    | 15 ++++++++++++++-
> > >   drivers/cxl/core/hdm.c         | 12 ++++++++++++
> > >   drivers/cxl/core/mce.c         |  8 ++++++--
> > >   drivers/cxl/core/pci.c         |  8 ++++++++
> > >   drivers/cxl/core/port.c        | 18 ++++++++++++++----
> > >   drivers/cxl/core/region_pmem.c |  6 ++++--
> > >   7 files changed, 61 insertions(+), 12 deletions(-)
> > > 
> > > 
> > > base-commit: d58772d8520c7ef247c4b95c9bd76d3a25da9ff5
> > > -- 
> > > 2.43.7
> > > 
> 
>