Re: Re: [PATCH 2/2] cxl/mbox: bound the Get Supported Logs entry count by the payload

[黄高彬]

> Similar to previous.  So far we aren't treating buggy devices as
> something we must harden against.  Where it is simple though we can
> do so.

Same framing as 1/2: this is hardening, and the Fixes: tag is dropped with the
commit message saying so rather than leaving it to be inferred.

The patch is now posted on its own as [PATCH v2] -- the event record patch from
the v1 series is withdrawn, because Anisa Su has the same fix in flight from
2026-08-31:

  https://lore.kernel.org/all/20260917104603.2658529-1-huanggaobin23@xxxxxxxxxx/

> +	*len = mbox_cmd.size_out;	/* bytes actually received */
> 
> blank line here.

Added.

> +	gsl_hdr = offsetof(struct cxl_mbox_get_supported_logs, entry);
> 
> 	gsl_hdr_size = struct_offset(gsl, entry);
> 
> Note the size is to make it clear this isnt a pointer to the gsl header.

Agreed on both; it is struct_offset(gsl, entry) named gsl_hdr_size now.

> +	max_entries = gsl_len > gsl_hdr ?
> +		      (gsl_len - gsl_hdr) / sizeof(gsl->entry[0]) : 0;
> 
> I'd error out first on it not being big enough for the header.
> Nothing else useful is going to happen and we know it will return
> an error anyway.

Done.  That removes the ternary and the underflow it was guarding, so the
comment about wrapping went with it:

	gsl_hdr_size = struct_offset(gsl, entry);
	if (gsl_len < gsl_hdr_size) {
		dev_err(dev,
			"GSL: response of %zu bytes is too short for the header\n",
			gsl_len);
		return -EIO;
	}

	max_entries = (gsl_len - gsl_hdr_size) / sizeof(gsl->entry[0]);

I used -EIO because that is what cxl_internal_send_cmd() returns for a payload
size mismatch; say if you would rather have -ENXIO and I will change it.  The
case is reachable: min_out is 2 and the header is 8 bytes, so a response of 2
to 7 bytes lands there.

Thanks,
Gaobin