linux-kernel - Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 21 May 2020 11:14:22 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Steven Price <steven.price@....com>, harb@...erecomputing.com,
        Will Deacon <will@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 +
 ARCH_SOC_ID support

On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote:
> Note that the warning should come up for either W=1 or C=1, and I also
> think that
> new code should generally be written sparse-clean and have no warnings with
> 'make C=1' as a rule.

No, absolutely not, that's a stupid idea, there are corner cases
where hiding a sparse warning is the wrong thing to do.  Look at
many of the cases in fs/ for example.

See https://lkml.org/lkml/2004/9/12/249 which should make anyone
who sees a use of __force in some random code stop and question
why it is there, and whether it is actually correct, or just there
to hide a sparse warning.

Remember, sparse is there to warn that something isn't quite right,
and the view taken is, if it isn't right, then we don't "cast the
warning away" with __force, even if we intend not to fix the code
immediately.

So, going for "sparse-clean" is actually not correct. Going for
"no unnecessary warnings" is.

And don't think what I've said above doesn't happen; I've rejected
patches from people who've gone around trying to fix every sparse
warning that they see by throwing __force incorrectly at it.

The thing is, if you hide all the warnings, even for incorrect code,
then sparse becomes completely useless to identify where things in
the code are not quite correct.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up