linux-kernel - Re: [PATCH] drm/amdgpu: Senseless code and unnecessary memset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 10 Apr 2022 03:50:25 +0300
From:   Grigory Vasilyev <h0tc0d3@...il.com>
To:     Christian König <christian.koenig@....com>
Cc:     Jani Nikula <jani.nikula@...el.com>,
        Rodrigo Siqueira <Rodrigo.Siqueira@....com>,
        Melissa Wen <mwen@...lia.com>,
        Alex Deucher <alexander.deucher@....com>,
        "Pan, Xinhui" <Xinhui.Pan@....com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>, Jiawei Gu <Jiawei.Gu@....com>,
        Lucas De Marchi <lucas.demarchi@...el.com>,
        amd-gfx list <amd-gfx@...ts.freedesktop.org>,
        Maling list - DRI developers 
        <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/amdgpu: Senseless code and unnecessary memset

Christian König in fact the compiler will very often replace {0} with
a memset call. I don't see a problem using {0} for local arrays with
primitive types.
There should also be no problem with memory alignment. Because the
compiler understands it. Using sizeof is also not a good idea.
More often everyone also makes mistakes with sizeof. It's best to
leave it as is, and there's no errors.
Indeed, when using structures and {0}, errors may occur, but I am not
aware of errors when using primitive types. I also looked at the
amdgpu code and  {0} is used in many places.
Also from experience malloc+memset is the most dangerous chain, can
silently damage memory, causing a bunch of subtle problems, and it is
better to replace them with more safe calloc.
Such a problem, for example, was recently found by me in fontconfig
and it crashed intel quartus. Therefore, where possible, I try to
avoid memset.

Regards, Grigory.

ср, 6 апр. 2022 г. в 17:43, Christian König <christian.koenig@....com>:
>
> Am 06.04.22 um 16:26 schrieb Jani Nikula:
> > On Tue, 05 Apr 2022, Christian König <christian.koenig@....com> wrote:
> >> Am 05.04.22 um 19:36 schrieb Grigory Vasilyev:
> >>> Using memset on local arrays before exiting the function is pointless.
> >>> Compilator will remove this code. Also for local arrays is preferable to
> >>> use {0} instead of memset. Mistakes are often made when working with
> >>> memset.
> >> Well actually memset is preferred when working with structures which are
> >> given to the hardware parser because {0} won't initialize paddings.
> > Not that I'd know anything that's going on here... but it sure seems
> > strange to me to be passing unpacked structures where the padding might
> > matter to a "hardware parser".
>
> Well to me it is an absolute miracle why the heck compilers don't
> initialize paddings.
>
> We had so many ups moments over the years and I really don't see why it
> should be more optimal to do this.
>
> Anyway, the memset() is used intentionally here and I don't really want
> to change it. What we could do is removing the second superfluous memset
> and use sizeof() instead of hard coding the size.
>
> Regards,
> Christian.
>
> >
> > *shrug*
> >
> >
> > BR,
> > Jani.
> >
> >
> >> So please don't use {0} in any of the atom bios code.
> >>
> >> Regards,
> >> Christian.
> >>
> >>> Signed-off-by: Grigory Vasilyev <h0tc0d3@...il.com>
> >>> ---
> >>>    drivers/gpu/drm/amd/amdgpu/atom.c | 8 +-------
> >>>    1 file changed, 1 insertion(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c b/drivers/gpu/drm/amd/amdgpu/atom.c
> >>> index be9d61bcb8ae..537e48fbbe6b 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> >>> @@ -1538,11 +1538,9 @@ struct atom_context *amdgpu_atom_parse(struct card_info *card, void *bios)
> >>>    int amdgpu_atom_asic_init(struct atom_context *ctx)
> >>>    {
> >>>     int hwi = CU16(ctx->data_table + ATOM_DATA_FWI_PTR);
> >>> -   uint32_t ps[16];
> >>> +   uint32_t ps[16] = {0};
> >>>     int ret;
> >>>
> >>> -   memset(ps, 0, 64);
> >>> -
> >>>     ps[0] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFSCLK_PTR));
> >>>     ps[1] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFMCLK_PTR));
> >>>     if (!ps[0] || !ps[1])
> >>> @@ -1551,10 +1549,6 @@ int amdgpu_atom_asic_init(struct atom_context *ctx)
> >>>     if (!CU16(ctx->cmd_table + 4 + 2 * ATOM_CMD_INIT))
> >>>             return 1;
> >>>     ret = amdgpu_atom_execute_table(ctx, ATOM_CMD_INIT, ps);
> >>> -   if (ret)
> >>> -           return ret;
> >>> -
> >>> -   memset(ps, 0, 64);
> >>>
> >>>     return ret;
> >>>    }
>