linux-kernel - Re: [PATCH] WARN_ONCE(): use bool for condition

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

Date:	Tue, 29 Sep 2009 20:11:58 -0300
From:	Cesar Eduardo Barros <cesarb@...arb.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	linux-kernel@...r.kernel.org, rolandd@...co.com, dwalker@...o99.com
Subject: Re: [PATCH] WARN_ONCE(): use bool for condition

Andrew Morton escreveu:
> On Sun, 27 Sep 2009 15:25:12 -0300
> Cesar Eduardo Barros <cesarb@...arb.net> wrote:
> 
>> Use the type bool for __ret_warn_once and __ret_warn_on, instead of int
>> with a double negation. This matches the intent of the code better and
>> should allow the compiler to generate better code, like in commit
>> 70867453092297be9afb2249e712a1f960ec0a09. However, some versions of gcc
>> seems to pessimize the code instead when the condition is not trivial.
> 
> There's a small reject in include/asm-generic/bug.h against current
> mainline, easily fixed.
> 
> It would be nice if we had some accurate numbers on the kernel size
> reductions from this, please.  I assume that the patch is still of
> benefit in 2.6.32-rc1(2?), but it's always good to confirm.

This one was the one where some compilers saw the size reduction and 
other compilers saw the size _increase_ due to bad code generation.

The good one was the first post in the original thread, "[PATCH] 
WARN_ONCE(): use bool for boolean flag" (the small reject you saw was 
probably because that one was not applied before this one, since this 
one was generated on top of that one).

In the first patch, Daniel Walker saw a decrease of 504 bytes in IA-32, 
and I saw a decrease of 1462 bytes in x86-64 defconfig. I will resend it 
as a reply to this email; I think it should be included, as there seems 
to be no obvious drawbacks.

For this one, on the other hand, I am not sure whether it should be 
included or dropped. While Daniel Walker saw a decrease of 84 bytes in 
IA-32, I saw an *increase* of 598 bytes in x86-64 defconfig. It seems 
the older compiler I am using (4.3.2-1ubuntu12) generates laughably bad 
code for it (setting the variable just to test it again in the next 
instruction).

Sorry for the confusion, I should have made more clear that both patches 
were separate and meant to be applied in sequence (and that the second 
one was under discussion).

-- 
Cesar Eduardo Barros
cesarb@...arb.net
cesar.barros@...il.com
--
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/