lkml.org 
[lkml]   [2020]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] drm/amdgpu/smu10: Replace one-element array and use struct_size() helper
From
Date
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 {

\
 
 \ /
  Last update: 2020-05-20 09:43    [W:0.061 / U:0.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site