public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "Winkler, Tomas" <tomas.winkler@intel.com>,
	"Lubart, Vitaly" <vitaly.lubart@intel.com>
Subject: Re: [Intel-gfx] [PATCH 02/15] mei: add support to GSC extended header
Date: Wed, 3 Aug 2022 22:07:46 +0000	[thread overview]
Message-ID: <e01e7373ee621dc27d410e762e810a4cdc246f4a.camel@intel.com> (raw)
In-Reply-To: <20220609231955.3632596-3-daniele.ceraolospurio@intel.com>

I was informed by Daniele that the MEI team had done the functional reviews as part of their differentiated "Signed-of-
by" process and so i was asked to only do a at the surface code-syntax / code-structure review. 

That said i did find one issue farther below.

I'm also compelled to add the following nit, but this is about prior code, not new code in these patches so you can
choose to ignore this: In mei_cl_irq_write, mei_cl_write and mei_cl_irq_read_msg functions, there are multiple blocks of
code that reference header-index, header-lenght, buffer-data, buffer-size, dr-slots and other ptr + sizing related
variables in different layers to decide validity of data, validity of size, ability for splitting data or extending via
dma-rings and other code flows I can't really make out. It would be nice to have separate helpers with self-explanatory
names and added comments about what these blocks of code are trying to do and how they interact with the e2e flow of
sending data or receiving data via the irq and message lists.


...alan


On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> From: Tomas Winkler <tomas.winkler@intel.com>
> 
> GSC extend header is of variable size and data
> is provided in a sgl list inside the header
> and not in the data buffers, need to enable the path.
> 
> diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c
> index 0706322154cb..0a0e984e5673 100644
> --- a/drivers/misc/mei/interrupt.c
> +++ b/drivers/misc/mei/interrupt.c
> @@ -98,9 +98,12 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
>  	struct mei_device *dev = cl->dev;
>  	struct mei_cl_cb *cb;
>  
> +	struct mei_ext_hdr_vtag *vtag_hdr = NULL;
> +	struct mei_ext_hdr_gsc_f2h *gsc_f2h = NULL;
> +
>  	size_t buf_sz;
>  	u32 length;
> -	int ext_len;
> +	u32 ext_len;
>  
>  	length = mei_hdr->length;
>  	ext_len = 0;
> @@ -122,18 +125,24 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
>  	}
>  
>  	if (mei_hdr->extended) {
> -		struct mei_ext_hdr *ext;
> -		struct mei_ext_hdr_vtag *vtag_hdr = NULL;
> -
> -		ext = mei_ext_begin(meta);
> +		struct mei_ext_hdr *ext = mei_ext_begin(meta);
>  		do {
>  			switch (ext->type) {
>  			case MEI_EXT_HDR_VTAG:
>  				vtag_hdr = (struct mei_ext_hdr_vtag *)ext;
>  				break;
> +			case MEI_EXT_HDR_GSC:
> +				gsc_f2h = (struct mei_ext_hdr_gsc_f2h *)ext;
> +				cb->ext_hdr = kzalloc(sizeof(*gsc_f2h), GFP_KERNEL);
> +				if (!cb->ext_hdr) {
> +					cb->status = -ENOMEM;
> +					goto discard;
> +				}
> +				break;
>  			case MEI_EXT_HDR_NONE:
>  				fallthrough;
>  			default:
> +				cl_err(dev, cl, "unknown extended header\n");
>  				cb->status = -EPROTO;
>  				break;
>  			}
> @@ -157,6 +168,28 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
>  		cb->vtag = vtag_hdr->vtag;
>  	}
>  
> +	if (gsc_f2h) {
> +		u32 ext_hdr_len = mei_ext_hdr_len(&gsc_f2h->hdr);
> +
> +		if (!dev->hbm_f_gsc_supported) {
> +			cl_err(dev, cl, "gsc extended header is not supported\n");
> +			cb->status = -EPROTO;
> +			goto discard;
> 
Alan: It looks to me that code jump where "discard" begins, puts cb back into a linked list for future re-use.
However, it doesn't free cb->ext_hdr (or at least from what i can tell). Thus, if we already allocated cb->ext_hdr (from
above when "case MEI_EXT_HDR_GSC:" is true, and if we end up discarding here or in the following few lines, then we may
end up leaking memory if we dont free cb->ext_hdr between discard and next reuse.

> +		}
> +
> +		if (length) {
> +			cl_err(dev, cl, "no data allowed in cb with gsc\n");
> +			cb->status = -EPROTO;
> +			goto discard;
> +		}
> +		if (ext_hdr_len > sizeof(*gsc_f2h)) {
> +			cl_err(dev, cl, "gsc extended header is too big %u\n", ext_hdr_len);
> +			cb->status = -EPROTO;
> +			goto discard;
> +		}
> +		memcpy(cb->ext_hdr, gsc_f2h, ext_hdr_len);
> +	}
> +
>  	if (!mei_cl_is_connected(cl)) {
>  		cl_dbg(dev, cl, "not connected\n");
>  		cb->status = -ENODEV;
> diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
> index 7c508bca9a00..862190b297aa 100644
> --- a/drivers/misc/mei/mei_dev.h
> +++ b/drivers/misc/mei/mei_dev.h
> @@ -211,6 +211,7 @@ struct mei_cl_cb {
>  	int status;
>  	u32 internal:1;
>  	u32 blocking:1;
> +	struct mei_ext_hdr *ext_hdr;
>  };
>  

  reply	other threads:[~2022-08-03 22:08 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
2022-06-09 23:19 ` [Intel-gfx] [PATCH 01/15] HAX: mei: GSC support for XeHP SDV and DG2 platform Daniele Ceraolo Spurio
2022-06-09 23:19 ` [Intel-gfx] [PATCH 02/15] mei: add support to GSC extended header Daniele Ceraolo Spurio
2022-08-03 22:07   ` Teres Alexis, Alan Previn [this message]
2022-08-16 20:49     ` Winkler, Tomas
2022-06-09 23:19 ` [Intel-gfx] [PATCH 03/15] mei: bus: enable sending gsc commands Daniele Ceraolo Spurio
2022-06-09 23:19 ` [Intel-gfx] [PATCH 04/15] mei: bus: extend bus API to support command streamer API Daniele Ceraolo Spurio
2022-06-09 23:19 ` [Intel-gfx] [PATCH 05/15] mei: pxp: add command streamer API to the PXP driver Daniele Ceraolo Spurio
2022-07-27  1:42   ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 06/15] mei: pxp: support matching with a gfx discrete card Daniele Ceraolo Spurio
2022-07-27  1:01   ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 07/15] drm/i915/pxp: load the pxp module when we have a gsc-loaded huc Daniele Ceraolo Spurio
2022-06-18  7:27   ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 08/15] drm/i915/pxp: implement function for sending tee stream command Daniele Ceraolo Spurio
2022-06-18  8:07   ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 09/15] drm/i915/pxp: add huc authentication and loading command Daniele Ceraolo Spurio
2022-06-21  6:33   ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 10/15] drm/i915/dg2: setup HuC loading via GSC Daniele Ceraolo Spurio
2022-07-05 22:35   ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 11/15] drm/i915/huc: track delayed HuC load with a fence Daniele Ceraolo Spurio
2022-07-06  4:42   ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 12/15] drm/i915/huc: stall media submission until HuC is loaded Daniele Ceraolo Spurio
2022-07-27  0:33   ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 13/15] drm/i915/huc: report HuC as loaded even if load still in progress Daniele Ceraolo Spurio
2022-07-06  4:49   ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2 Daniele Ceraolo Spurio
2022-06-22 17:55   ` Teres Alexis, Alan Previn
2022-06-22 18:16   ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 15/15] HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI Daniele Ceraolo Spurio
2022-06-10  0:07 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HuC loading for DG2 Patchwork
2022-06-10  0:07 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-06-10  8:01 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-06-11  8:01 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-06-13  8:16 ` [Intel-gfx] [PATCH 00/15] " Tvrtko Ursulin
2022-06-13 15:39   ` Ceraolo Spurio, Daniele
2022-06-13 16:31     ` Tvrtko Ursulin
2022-06-13 16:41       ` Ceraolo Spurio, Daniele
2022-06-13 16:56         ` Tvrtko Ursulin
2022-06-13 17:06           ` Ceraolo Spurio, Daniele
2022-06-13 17:39             ` Tvrtko Ursulin
2022-06-13 18:13               ` Ceraolo Spurio, Daniele
2022-06-14  7:44                 ` Tvrtko Ursulin
2022-06-14 15:30                   ` Ceraolo Spurio, Daniele
2022-06-14 23:15                     ` Ye, Tony
2022-06-15 10:13                       ` Tvrtko Ursulin
2022-06-15 14:35                         ` Ceraolo Spurio, Daniele
2022-06-15 14:53                           ` Tvrtko Ursulin
2022-06-15 16:14                         ` Ye, Tony
2022-06-16  2:28                           ` Zhang, Carl
2022-07-05 23:30                             ` Ceraolo Spurio, Daniele
2022-07-06 17:26                               ` Ye, Tony
2022-07-06 19:29                                 ` Ceraolo Spurio, Daniele
2022-07-06 20:11                                   ` Ye, Tony
2022-06-16  7:10                           ` Tvrtko Ursulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e01e7373ee621dc27d410e762e810a4cdc246f4a.camel@intel.com \
    --to=alan.previn.teres.alexis@intel.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tomas.winkler@intel.com \
    --cc=vitaly.lubart@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox