linux-kernel - Re: Bloatwatch 2.6.28-rc1: i8042 DMI lookup tables

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]

Message-Id: <200810242046.02743.dmitry.torokhov@gmail.com>
Date:	Fri, 24 Oct 2008 20:46:02 -0400
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Jiri Kosina <jkosina@...e.cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: Bloatwatch 2.6.28-rc1: i8042 DMI lookup tables

On Friday 24 October 2008, Matt Mackall wrote:
> On Sat, 2008-10-25 at 00:15 +0200, Jiri Kosina wrote:
> > On Fri, 24 Oct 2008, Matt Mackall wrote:
> > 
> > > We've added 12k of new initdata to allnoconfig builds for i8042 DMI
> > > lookup tables:
> > > 
> > > http://www.selenic.com/bloatwatch/?cmd=compare;v1=2.6.27;v2=2.6.28-rc1;part=/built-in/drivers
> > > 
> > > It looks like each table entry is > 320 bytes as we reserve four 80-byte
> > > slots in each for DMI match strings. 
> > 
> > Umm, and what is the actual problem with that, really?
> 
> The actual problem is that if the kernel grows by 12k every time a
> developer says "what's the big deal?" the kernel will become very large
> indeed.
> 
> > OK, we can remove it from .init, but then it will be rotting in memory 
> > forever, which is quite sub-optimal, when this kind of DMI information is 
> > needed only during initialization.
> 
> I wasn't complaining that they were in init, but rather that they were
> 12k. For something like 37 entries. The entry size is ridiculous and
> looks to have grown by a factor of 10 since 2.6.27. What, as they say,
> is up with that?
> 
> It looks like David Woodhouse is to blame:
> 
> commit d945b697d0eea5a811ec299c5f1a25889bb0242b
> Automatic MODULE_ALIAS() for DMI match tables.
> 
> This is probably also responsible for most of the growth in x86 I
> mentioned elsewhere, so it's about 25-30k damage in total. David?
> 

I think that the net effect of this change is positive. While it is
true that the size of the kernel image grew we do discard more memory
(most of DMI tables are marked __initdata) than we were able to do
before DMI strings were embedded into dmi_strmatch so the footprint of
the running kernel now should be smaller. Having said this I wonder if
we could reduce the length of these strings form 79 to let's say 39. 

I would like to get rid of .ident strings in cases when drivers don't
use them for anything, this should free some more memory.

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