On 12/02/25 02:32, Bjorn Helgaas wrote:
On Mon, Feb 10, 2025 at 04:03:26PM -0700, Keith Busch wrote:
On Mon, Feb 10, 2025 at 06:57:40PM +0530, Purva Yeshi wrote:
Fix warning detected by smatch tool:
Array of flexible structure occurs in 'pci_saved_state' struct
The warning occurs because struct pci_saved_state contains struct
pci_cap_saved_data cap[], where cap[] has a flexible array member (data[]).
Arrays of structures with flexible members are not allowed, leading to this
warning.
Replaced cap[] with a pointer (*cap), allowing dynamic memory allocation
instead of embedding an invalid array of flexible structures.
Signed-off-by: Purva Yeshi <purvayeshi550@xxxxxxxxx>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 869d204a7..648a080ef 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1929,7 +1929,7 @@ EXPORT_SYMBOL(pci_restore_state);
struct pci_saved_state {
u32 config_space[16];
- struct pci_cap_saved_data cap[];
+ struct pci_cap_saved_data *cap;
};
I don't think this is right. Previously the space for "cap" was
allocated at the end of the pci_saved_state, but now it's just an
uninitialized pointer.
Thanks, I think you're right. Dropped pending fix or better
explanation.
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.
Bjorn
Thanks for the explanation. The primary goal of the patch was to address
the Smatch warning regarding the flexible array member inside
'pci_cap_saved_data'. However, from the explanation, I now got that the
current approach may not be ideal.
