Applied. thanks! Alex On Wed, May 20, 2020 at 3:42 AM Christian König <christian.koenig@xxxxxxx> wrote: > > Am 20.05.20 um 00:55 schrieb Gustavo A. R. Silva: > > The current codebase makes use of one-element arrays in the following > > form: > > > > struct something { > > int length; > > u8 data[1]; > > }; > > > > struct something *instance; > > > > instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL); > > instance->length = size; > > memcpy(instance->data, source, size); > > > > but the preferred mechanism to declare variable-length types such as > > these ones is a flexible array member[1][2], introduced in C99: > > > > struct foo { > > int stuff; > > struct boo array[]; > > }; > > > > By making use of the mechanism above, we will get a compiler warning > > in case the flexible array does not occur last in the structure, which > > will help us prevent some kind of undefined behavior bugs from being > > inadvertently introduced[3] to the codebase from now on. So, replace > > the one-element array with a flexible-array member. > > > > Also, make use of the new struct_size() helper to properly calculate the > > size of struct smu10_voltage_dependency_table. > > > > This issue was found with the help of Coccinelle and, audited and fixed > > _manually_. > > > > [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FZero-Length.html&data=02%7C01%7Cchristian.koenig%40amd.com%7C8a400bdb88924a1d951508d7fc471966%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255254622039268&sdata=ILOPPn17c%2B3oyLLdh%2BgH2b%2B8RdhWuTFGxruRD7GUHOo%3D&reserved=0 > > [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F21&data=02%7C01%7Cchristian.koenig%40amd.com%7C8a400bdb88924a1d951508d7fc471966%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255254622039268&sdata=lCr5Otij55Snq27BDp4RmtW4hNhOS%2Bm4vSUOOAz07XA%3D&reserved=0 > > [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") > > > > Signed-off-by: Gustavo A. R. Silva <gustavoars@xxxxxxxxxx> > > Acked-by: Christian König <christian.koenig@xxxxxxx> > > May I suggest that we add a section how to correctly do this to > Documentation/process/coding-style.rst or similar document? > > I've seen a bunch of different approaches and some even doesn't work > with some gcc versions and result in a broken binary. > > Thanks, > Christian. > > > --- > > drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 6 ++---- > > drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h | 2 +- > > 2 files changed, 3 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c > > index 246bb9ac557d8..c9cfe90a29471 100644 > > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c > > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c > > @@ -410,12 +410,10 @@ static int smu10_get_clock_voltage_dependency_table(struct pp_hwmgr *hwmgr, > > struct smu10_voltage_dependency_table **pptable, > > uint32_t num_entry, const DpmClock_t *pclk_dependency_table) > > { > > - uint32_t table_size, i; > > + uint32_t i; > > struct smu10_voltage_dependency_table *ptable; > > > > - table_size = sizeof(uint32_t) + sizeof(struct smu10_voltage_dependency_table) * num_entry; > > - ptable = kzalloc(table_size, GFP_KERNEL); > > - > > + ptable = kzalloc(struct_size(ptable, entries, num_entry), GFP_KERNEL); > > if (NULL == ptable) > > return -ENOMEM; > > > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h > > index 1fb296a996f3a..0f969de10fabc 100644 > > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h > > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h > > @@ -192,7 +192,7 @@ struct smu10_clock_voltage_dependency_record { > > > > struct smu10_voltage_dependency_table { > > uint32_t count; > > - struct smu10_clock_voltage_dependency_record entries[1]; > > + struct smu10_clock_voltage_dependency_record entries[]; > > }; > > > > struct smu10_clock_voltage_information { > > _______________________________________________ > amd-gfx mailing list > amd-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel