linux-kernel - Re: [PATCH] firmware: arm_scmi: Eliminate local db variable in SCMI_PERF_FC_RING

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]

Message-ID: <20190812103246.GA28585@e107155-lin>
Date:   Mon, 12 Aug 2019 11:32:48 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Nathan Chancellor <natechancellor@...il.com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        clang-built-linux@...glegroups.com
Subject: Re: [PATCH] firmware: arm_scmi: Eliminate local db variable in
 SCMI_PERF_FC_RING_DB

On Fri, Aug 09, 2019 at 09:49:10PM -0700, Nathan Chancellor wrote:
> clang warns four times:
>
> drivers/firmware/arm_scmi/perf.c:320:24: warning: variable 'db' is
> uninitialized when used within its own initialization [-Wuninitialized]
>                 SCMI_PERF_FC_RING_DB(db, 64);
>                 ~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> drivers/firmware/arm_scmi/perf.c:300:31: note: expanded from macro
> 'SCMI_PERF_FC_RING_DB'
>         struct scmi_fc_db_info *db = doorbell;          \
>                                 ~~   ^~~~~~~~
>
> This happens because the doorbell identifier becomes db after
> preprocessing:
>
>         if (db->width == 1)
>                 do {
>                         u8 val = 0;
>                         struct scmi_fc_db_info *db = db;
>                         if (db->mask)
>                                 val = ioread8(db->addr) & db->mask;
>                         iowrite8((u8)db->set | val, db->addr);
>                 } while (0);
>
> We could swap the doorbell and db identifiers within the macro and that
> would resolve the issue; however, there doesn't appear to be a good
> reason for having two copies of the same variable. Eliminate the one in
> the do while loop to prevent this warning and make the code clearer.
>

I originally had exactly what we will after this patch applied. I think
one of the tool complained about argument 'db' reused in the macro
might have possible side-effects. That's the reason I moved it. I will
dig it up and fold this in the original patch as before.

--
Regards,
Sudeep