linux-kernel - Re: [PATCH] staging: vchiq: add 'static' to function definition

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: <67bef642-a301-e825-142c-afcfe8c898a1@gmail.com>
Date:   Mon, 31 Oct 2022 14:54:18 +1100
From:   "Scott J. Crouch" <scottjcrouch@...il.com>
To:     Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@...adcom.com>,
        kernel-janitors@...r.kernel.org,
        linux-rpi-kernel@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: vchiq: add 'static' to function definition

On 30/10/22 21:46, Arnd Bergmann wrote:
> Hmm, I see an of_node_put() between devm_rpi_firmware_get() and the
> error check. With OF_DYNAMIC=y, this is an external function call, so
> I guess gcc can no longer assume that drvdata->fw is NULL after that,
> so it doesn't make this optimization.

Ah, of course, you're right.

> Ok, I see. My best guess would be OF_DYNAMIC

I checked and you are correct.

> but I don't actually see how that changes anything in this file

Yeah.  I had a look as well and I'm similarly puzzled.

> This would mean you only get a warning when both RASPBERRYPI_FIRMWARE
> and OF_DYNAMIC are disabled. If you can confirm that, adding a dependency
> on RASPBERRYPI_FIRMWARE is still the correct fix.

It builds ok as long as OF_DYNAMIC is set; RASPBERRYPI_FIRMWARE doesn't need
setting (maybe since devm_rpi_firmware_get() is a static inline it's optimized
differently?).  Perhaps RASPBERRYPI_FIRMWARE ought to be made a dependency in
any case, but since it depends on ARCH_BCM2835, doing so will mean one is
unable to test-compile/run sparse on x86.  Which is fine; I wouldn't expect to
be able to; I'm not really sure what accommodations (if any) are usually made
in this regard with respect to drivers.

Scott.