Re: Re: [PATCH RESEND] cxl/mbox: validate the DCD extent list counts against the payload

[黄高彬]

Hi Anisa,

Thank you for the pointer, and sorry for the slow reply -- I had not found
your series.  Since you have the fix in your tree, I am withdrawing this patch
rather than carrying a second copy of it, and I will not repost it.

> Sashiko reported the same issue on the previous revision ... and I have
> already patched it in my working tree.

If it is useful, we have a reproduction from a QEMU Type-3 device that lies in
the Get DC Extent List response, with the boundary measured rather than
inferred.  The response header is 16 bytes and an extent is 40, so a 2048 byte
mailbox buffer holds 50: returned_extent_count = 50 stays inside it, 51 is the
first that reads past the end (KASAN in cxl_validate_extent, Read of size 2,
extent->shared_extn_seq), and 4096 fails the same way.  A device reporting
total_extent_count = 100000 with returned_extent_count = 0 instead spins region
bring-up until the guest stops answering console commands -- that one is not
covered by a count check, because zero extents fit any payload.

Our version ended up doing what I think yours does: reject a count that does
not fit the payload with -EIO, and fail with -EIO when a response makes no
progress.  Yours supersedes it.  Happy to send the sweep as test cases, or to
run it against your series once it is posted.

> If the original send failed and did not make it to the mailing list, there's
> no need to prefix this patch with RESEND.

Noted, thank you.  The list did receive the first posting; what bounced was a
maintainer address in the Cc list, so the RESEND prefix was misleading.  There
is nothing to re-post now in any case.

> I plan to post the next revision after the DCD Prep Series is complete:
> https://lore.kernel.org/linux-cxl/20260918203049.7273-1-anisa.su@xxxxxxxxxxx/T/#t
> You are welcome to review both.

I will follow both.  Jonathan's point earlier in this thread was right as well:
a snippet in the series thread would have been a better shape than a standalone
patch.

One more thing, since we were testing the older `dcd-v6-2025-04-13` branch: a
device that returns one partition and then zero while still claiming more
available makes `cxl_dev_dc_identify()` loop without progress (7.4 million
queries on our QEMU device, and the guest never reaches a shell).  v11 already
guards that with the `rc == 0` check, so there is nothing to report -- just
confirming that the case we can reproduce is covered, and that the zero-progress
shape is reachable rather than theoretical.

> ... monthly meeting at 11AM PST every 3rd Tuesday of the month.  So the next
> one is Tuesday October 20 11AM PST.  If you would like to attend, I can
> forward the invite to you.

Thank you for the offer -- I will pass on the invite for now, but I will keep
following the published notes (https://pmem.io/ndctl/collab/).  If something on
the call needs the author of this series, I am happy to join for that.

Gaobin