public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Purva Yeshi <purvayeshi550@gmail.com>,
	 bhelgaas@google.com, skhan@linuxfoundation.org,
	linux-pci@vger.kernel.org,  linux-kernel@vger.kernel.org,
	Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH] drivers: pci: Fix flexible array usage
Date: Thu, 13 Feb 2025 16:41:40 +0200 (EET)	[thread overview]
Message-ID: <ccdd2c39-1b28-551f-decf-e0d7609f2464@linux.intel.com> (raw)
In-Reply-To: <Z6u-pwlktLnPZNF-@kbusch-mbp>

On Tue, 11 Feb 2025, Keith Busch wrote:

> On Tue, Feb 11, 2025 at 03:02:35PM -0600, Bjorn Helgaas wrote:
> > This is kind of a complicated data structure.  IIUC, a struct
> > pci_saved_state is allocated only in pci_store_saved_state(), where
> > the size is determined by the sum of the sizes of all the entries in
> > the dev->saved_cap_space list.
> > 
> > The pci_saved_state is filled by copying from entries in the
> > dev->saved_cap_space list.  The entries need not be all the same size
> > because we copy each entry manually based on its size.
> > 
> > So cap[] is really just the base of this buffer of variable-sized
> > entries.  Maybe "struct pci_cap_saved_data cap[]" is not the best
> > representation of this, but *cap (a pointer) doesn't seem better.
> 
> The original code is actually correct despite using a flexible array of
> a struct that contains a flexible array. That arrangement just means you
> can't index into it, but the code is only doing pointer arithmetic, so
> should be fine.
> 
> With this struct:
> 
> struct pci_saved_state {
>  	u32 config_space[16];
> 	struct pci_cap_saved_data cap[];
> };
> 
> Accessing "cap" field returns the address right after the config_space[]
> member. When it's changed to a pointer type, though, it needs to be
> initialized to *something* but the code doesn't do that. The code just
> expects the cap to follow right after the config.
> 
> Anyway, to silence the warning we can just make it an anonymous member
> and add 1 to the state to get to the same place in memory as before.
> 
> ---
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 869d204a70a37..e562037644fd0 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1929,7 +1929,6 @@ EXPORT_SYMBOL(pci_restore_state);
>  
>  struct pci_saved_state {
>  	u32 config_space[16];
> -	struct pci_cap_saved_data cap[];

Can't just [] be dropped from it (and removed from the size calculation)?

It's not a real flex array because the second pci_cap_saved_data is not at 
->cap[1] but calculated by the loop by adding in the data in between. But 
there's one entry at ->cap[0] which is same as ->cap, no need to make it 
a flex array at all, IMO.

>  };
>  
>  /**
> @@ -1961,7 +1960,7 @@ struct pci_saved_state *pci_store_saved_state(struct pci_dev *dev)
>  	memcpy(state->config_space, dev->saved_config_space,
>  	       sizeof(state->config_space));
>  
> -	cap = state->cap;
> +	cap = (void *)(state + 1);
>  	hlist_for_each_entry(tmp, &dev->saved_cap_space, next) {
>  		size_t len = sizeof(struct pci_cap_saved_data) + tmp->cap.size;
>  		memcpy(cap, &tmp->cap, len);
> @@ -1991,7 +1990,7 @@ int pci_load_saved_state(struct pci_dev *dev,
>  	memcpy(dev->saved_config_space, state->config_space,
>  	       sizeof(state->config_space));
>  
> -	cap = state->cap;
> +	cap = (void *)(state + 1);
>  	while (cap->size) {
>  		struct pci_cap_saved_state *tmp;
>  
> --
> 

-- 
 i.


  parent reply	other threads:[~2025-02-13 14:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-10 13:27 [PATCH] drivers: pci: Fix flexible array usage Purva Yeshi
2025-02-10 22:47 ` Bjorn Helgaas
2025-02-10 23:03 ` Keith Busch
2025-02-11 21:02   ` Bjorn Helgaas
2025-02-11 21:18     ` Keith Busch
2025-02-13 10:48       ` Purva Yeshi
2025-02-13 14:41       ` Ilpo Järvinen [this message]
2025-02-13 10:42     ` Purva Yeshi
2025-02-13 10:37   ` Purva Yeshi

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=ccdd2c39-1b28-551f-decf-e0d7609f2464@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=purvayeshi550@gmail.com \
    --cc=skhan@linuxfoundation.org \
    /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