error: invalid use of flexible array member in sound/soc/sof/topology.c

[GustavoARSilva]

The following patch causes an 'invalid use of flexible array member' error:

diff --git a/include/sound/sof/topology.h b/include/sound/sof/topology.h
index d12736e14b69..adee6afd1490 100644
--- a/include/sound/sof/topology.h
+++ b/include/sound/sof/topology.h
@@ -237,7 +237,7 @@ struct sof_ipc_comp_process {
        /* reserved for future use */
        uint32_t reserved[7];

-       uint8_t data[0];
+       uint8_t data[];
 } __packed;

 /* frees components, buffers and pipelines

error: invalid use of flexible array member:

sound/soc/sof/topology.c: In function ‘sof_process_load’:
sound/soc/sof/topology.c:2167:47: error: invalid use of flexible array member
 2167 |                         memcpy(&process->data + offset,
      |                                               ^
./include/linux/fortify-string.h:360:44: note: in definition of macro ‘__fortify_memcpy_chk’
  360 |         fortify_memcpy_chk(__fortify_size, p_size, q_size,              \
      |                                            ^~~~~~
sound/soc/sof/topology.c:2167:25: note: in expansion of macro ‘memcpy’
 2167 |                         memcpy(&process->data + offset,
      |                         ^~~~~~
sound/soc/sof/topology.c:2167:47: error: invalid use of flexible array member
 2167 |                         memcpy(&process->data + offset,
      |                                               ^
./include/linux/fortify-string.h:361:28: note: in definition of macro ‘__fortify_memcpy_chk’
  361 |                            p_size_field, q_size_field, #op);            \
      |                            ^~~~~~~~~~~~
sound/soc/sof/topology.c:2167:25: note: in expansion of macro ‘memcpy’
 2167 |                         memcpy(&process->data + offset,
      |                         ^~~~~~
sound/soc/sof/topology.c:2167:47: error: invalid use of flexible array member
 2167 |                         memcpy(&process->data + offset,
      |                                               ^
./include/linux/fortify-string.h:362:27: note: in definition of macro ‘__fortify_memcpy_chk’
  362 |         __underlying_##op(p, q, __fortify_size);                        \
      |                           ^
sound/soc/sof/topology.c:2167:25: note: in expansion of macro ‘memcpy’
 2167 |                         memcpy(&process->data + offset,
      |                         ^~~~~~

[skitt]

Yes, data can no longer be used as a pointer in that way:

diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index e72dcae5e7ee..1d119d1dd69d 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -2164,7 +2164,7 @@ static int sof_process_load(struct snd_soc_component *scomp, int index,
         */
        if (ipc_data_size) {
                for (i = 0; i < widget->num_kcontrols; i++) {
-                       memcpy(&process->data + offset,
+                       memcpy(&process->data[offset],
                               wdata[i].pdata->data,
                               wdata[i].pdata->size);
                        offset += wdata[i].pdata->size;

[GustavoARSilva]

Yes, data can no longer be used as a pointer in that way:

diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index e72dcae5e7ee..1d119d1dd69d 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -2164,7 +2164,7 @@ static int sof_process_load(struct snd_soc_component *scomp, int index,
         */
        if (ipc_data_size) {
                for (i = 0; i < widget->num_kcontrols; i++) {
-                       memcpy(&process->data + offset,
+                       memcpy(&process->data[offset],
                               wdata[i].pdata->data,
                               wdata[i].pdata->size);
                        offset += wdata[i].pdata->size;

Yep; please, feel free to send a proper patch for this if you wish to (and add a link to this issue in the changelog text). :)

[skitt]

Thanks, I’ll take care of it in the next day or two.

[GustavoARSilva]

Mark Brown just took a fix for this issue in his -next tree: https://lore.kernel.org/lkml/164512273904.3993052.15786188783009967860.b4-ty@kernel.org/