linux-kernel - Re: [PATCH] ring_buffer: fix ring_buffer_event

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, 8 Jan 2009 12:55:30 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Robert Richter <robert.richter@....com>
Subject: Re: [PATCH] ring_buffer: fix ring_buffer_event_length()


* Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Wed, 7 Jan 2009 23:58:39 -0500 (EST) Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> >  kernel/trace/ring_buffer.c |    8 +++++++-
> 
> <looks>
> 
> heavens, what a lot of inlining.  Looks like something from 1997 :)
> 
> Prove me wrong!
> 
> 
> From: Andrew Morton <akpm@...ux-foundation.org>
> 
>           text    data     bss     dec     hex filename
> before:  11320     228       8   11556    2d24 kernel/trace/ring_buffer.o
> after:   10592     228       8   10828    2a4c kernel/trace/ring_buffer.o

You are wrong :-)

With x86 defconfig and gcc 4.3.2 i get zero change in size:

  kernel/trace/ring_buffer.o:

     text	   data	    bss	    dec	    hex	filename
    11485	    228	      8	  11721	   2dc9	ring_buffer.o.before
    11485	    228	      8	  11721	   2dc9	ring_buffer.o.after

  md5:
     55447563cd459bbb02c6234b2544fcc2  ring_buffer.o.before.asm
     55447563cd459bbb02c6234b2544fcc2  ring_buffer.o.after.asm

(i took out the free_page() bit to only measure the inlining)

That is the same with and without CONFIG_OPTIMIZE_INLINING - i.e. recent 
GCC gets the inlining right.

Really, we should stop bothering about inlines on the source code level 
(the kernel has 20,000 inlines and around 100,000 functions - do we really 
want to maintain inlining information on a per function basis?) - and we 
should tell the GCC folks when the compiler messes up some detail.

Or if GCC messes up inlining so much in the future that we cannot live 
with it, we can go back to "always inline" and manual annotations again. 
Or write a new compiler. (the latter is probably less work ;-)

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