linux-kernel - Look Ma, da kernel is b0rken

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-next>] [day] [month] [year] [list]

Message-ID: <20121205070901.GA12123@rhlx01.hs-esslingen.de>
Date:	Wed, 5 Dec 2012 08:09:01 +0100
From:	Andreas Mohr <andi@...as.de>
To:	linux-kernel@...r.kernel.org
Cc:	Li Shaohua <shaohua.li@...el.com>, linux-acpi@...r.kernel.org
Subject: Look Ma, da kernel is b0rken

Hi,

drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi':
drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively
exhaustive tests is always true [-Wlogical-op]
drivers/pnp/pnpacpi/core.c:66:2: warning: logical 'or' of collectively
exhaustive tests is always true [-Wlogical-op]
drivers/pnp/pnpacpi/core.c:67:2: warning: logical 'or' of collectively
exhaustive tests is always true [-Wlogical-op]

That's already the second less enticing -Wlogical-op issue
which was discovered by accident during less than two days
of my happy(?) activity of kernel suspend breakage bisection.

Why oh why, as a rather *very* critical piece of software,
can't the kernel use sufficiently aggressive warning levels *by default*??
IMHO it's simply NOT ACCEPTABLE to have such sloppiness creep into
the daily bandwagon of kernel development life
(or should I say: being mandated to creep in?).

Result: whichever default warning level you set
*will* end up as The New Normal,
and all those warnings which then remain able to rear their ugly heads
according to the chosen default level
will be fixed by the community eventually,
and *most others won't* (or at least not in time).

The amount of warnings spewn by make W=3 (or even W=2) is simply
shocking IMNSHO.
And there can always be an argument that most of such warnings
are fixable. If not directly (e.g. because analysis of that warning type
is partially unreliable), then by actively reworking code
into something slightly different.

So, unless there are very hard and *justified* reasons
for keeping builds at such lame-*ss defaults
(such as automated compliance test runs which may not fail -
but in such cases one could argue that *those* uses
should then be required to manually lessen *their* warning level settings),
I would strongly vote for having a hard discussion about the status
quo.

As a somewhat aggravating comment, please note that this warning
actually seems to date back to 1da177e (initial repository build)
according to blame on that file.

Andreas Mohr

P.S.: sorry for the subject line ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/