linux-kernel - Re: [PATCH] move omap_udc's probe function to .devinit.text

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:	Sun, 12 Jul 2009 14:17:32 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Cc:	David Brownell <david-b@...bell.net>, Greg KH <gregkh@...e.de>,
	linux-kernel@...r.kernel.org,
	Philipp Zabel <philipp.zabel@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tony Lindgren <tony@...mide.com>,
	Dmitry Baryshkov <dbaryshkov@...il.com>
Subject: Re: [PATCH] move omap_udc's probe function to .devinit.text

On Sun, Jul 12, 2009 at 09:47:34AM +0100, Russell King wrote:
> Your approach is perfectly fine, and safe.  You're not adding any
> additional bloat which isn't already there.  If it were adding any
> bloat (which it isn't), it certainly is not "in chunks of up to a
> page per patch".

Here is the effect of applying the am79c961 patch:

   text    data     bss     dec     hex filename
2553829   76608   78560 2708997  295605 vmlinux.patched
2553285   76608   78560 2708453  2953e5 vmlinux

that's an extra 500 bytes, but wait a moment before criticising that.
Let's look at where these came from:

before:
  1 .text.head    00000240  c0008000  c0008000  00010000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .init         00016dc0  c0008240  c0008240  00010240  2**5
                  CONTENTS, ALLOC, LOAD, CODE
  3 .text         002455a4  c001f000  c001f000  00027000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 __ksymtab     00004198  c0265000  c0265000  0026d000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

after:
  1 .text.head    00000240  c0008000  c0008000  00010000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .init         00016dc0  c0008240  c0008240  00010240  2**5
                  CONTENTS, ALLOC, LOAD, CODE
  3 .text         002457c4  c001f000  c001f000  00027000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 __ksymtab     00004198  c0265000  c0265000  0026d000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

Notice that the VMA of __ksymtab hasn't changed, which follows on from
the text section.  What's happened is that we've merely moved some text
from the .init section to the .text section, and in this case we haven't
changed the overall file size, nor the number of pages used for each
section.

To nack these patches based upon every patch adding one page to the kernel
size is clearly overstating the effect.  The effect is that in some
configurations, it moves some text out of .init into .text, and can
increase the size of the kernel kept in memory after boot time.  It's
certainly no where near "one page per patch" though, and the overall
size of the kernel may only change +/- one page through doing this -
eg, you might move enough text out of .init so that shrinks by one
page without making .text expand by a page.

I don't think this is a strong enough reason to reject any of these
patches.  David's approach is an enhancement whereas your patches
are a bug fix.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/