linux-kernel - Re: [patch 1/3] move WARN

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]

Message-ID: <477FC613.7020807@linux.intel.com>
Date:	Sat, 05 Jan 2008 10:01:55 -0800
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch 1/3] move WARN_ON() out of line

Jeremy Fitzhardinge wrote:
> Arjan van de Ven wrote:
>> This patch moves WARN_ON() out of line entirely. I've considered keeping
>> the test inline and moving only the slowpath out of line, but I decided
>> against that: an out of line test reduces the pressure on the CPUs
>> branch predictor logic and gives smaller code, while a function call
>> to a fixed location is quite fast. Likewise I've considered doing
>> something
>> similar to BUG() (eg use a trapping instruction) but that's not really
>> better (it needs the test inline again and recovering from an invalid
>> instruction isn't quite fun).
> 
> Power implements WARN_ON this way, and all the machinery is in place to
> generically implement WARN_ON that way if you want.  It does generate
> denser code than the call (since its just a single trapping instruction
> with no need for argument setup), and the performance cost of the trap
> shouldn't matter if warnings are rare (which one would hope).

I just did an experiment with this to see how much is on the table. I made
a file with 1024 WARN_ON()'s (new style, eg the out of line call) and 1024 BUG_ON()'s,
which on i386 already use the trap.
This shows that the BUG_ON() case is 2Kb shorter in generated code. From this 2Kb you
need to subtract all the code size that is needed to deal with the trap and the module
merging/unmerging of trap points etc etc, so lets say that a total of 1Kb is left on the table.
HOWEVER, if you have a module with, say, only 4 WARN_ON()/BUG_ON()'s, you actually LOOSE
48 bytes, because of the extra overhead of how the trap data is stored.

So... call me unconvinced for now. There's 30 Kb on the table with the easy, obviously safe
transform, and maybe another 1Kb with the much more tricky trapping scenario, but only
for the vmlinux case; the module case seems to be a loss instead.

--
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/