| Message ID | 20200519225545.GA2066@embeddedor (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/amdgpu/smu10: Replace one-element array and use struct_size() helper | expand |
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@kernel.org> Acked-by: Christian König <christian.koenig@amd.com> 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 {
Applied. thanks! Alex On Wed, May 20, 2020 at 3:42 AM Christian König <christian.koenig@amd.com> 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@kernel.org> > > Acked-by: Christian König <christian.koenig@amd.com> > > 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On Wed, May 20, 2020 at 09:42:27AM +0200, Christian König wrote: > > > > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > > Acked-by: Christian König <christian.koenig@amd.com> > > May I suggest that we add a section how to correctly do this to > Documentation/process/coding-style.rst or similar document? > That's already on my list. :) > I've seen a bunch of different approaches and some even doesn't work with > some gcc versions and result in a broken binary. > Do you have an example of that one that doesn't work with some GCC versions? It'd be interesting to take a look... Thanks -- Gustavo
On Fri, May 22, 2020 at 1:46 PM Gustavo A. R. Silva <gustavoars@kernel.org> wrote: > > On Wed, May 20, 2020 at 09:42:27AM +0200, Christian König wrote: > > > > > > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > > > > Acked-by: Christian König <christian.koenig@amd.com> > > > > May I suggest that we add a section how to correctly do this to > > Documentation/process/coding-style.rst or similar document? > > > > That's already on my list. :) > > > I've seen a bunch of different approaches and some even doesn't work with > > some gcc versions and result in a broken binary. > > > > Do you have an example of that one that doesn't work with some GCC > versions? It'd be interesting to take a look... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/radeon/radeon_atombios.c?id=a7ee824a6255e347ea76e2f00827e81bbe01004e Alex > > Thanks > -- > Gustavo > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
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 {
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://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> --- 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(-)