linux-kernel - Re: [RFC] remove implicit slab.h inclusion from percpu.h

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, 16 Mar 2010 08:57:26 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Tejun Heo <tj@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	penberg@...helsinki.fi, adobriyan@...il.com
Subject: Re: [RFC] remove implicit slab.h inclusion from percpu.h


* Tejun Heo <tj@...nel.org> wrote:

> Hello,
> 
> On 03/16/2010 03:54 PM, Tejun Heo wrote:
>
> > Maybe a better way is to grab for slab API usages in .c files which don't 
> > have slab.h inclusion.  If breaking the dependency is the way to go, I can 
> > definitely write up some scripts and do test builds on some archs.  There 
> > sure will be some fallouts but I think it won't be too bad.
> 
> Hmmm... here are some interesting numbers.  Not completely exact but should 
> give the general ballpark idea.
> 
> all .c files					: 13999
> .c files which use any of slab interface	:  5603
> .c files which include slab.h			:  2519
> .c files which include slab.h but don't use it	:   577
> .c files which use slab but don't include it	:  3661
> 
> .c files with k[mzc]alloc/k[z]free usage	:  5291
> .c files with other slab interface usage	:   356
> 
> C files which use k[mzc]alloc/k[z]free covers ~38% of all c files. One 
> possibility is to separate out those into kmalloc.h and make it available 
> universally via kernel.h.

Well, that's the main question: do we want all-in-one big headers like 
kernel.h (and sched.h / mm.h) or not?

If we want to avoid combo .h files then we inevitably want to go for 
finegrained, per subsystem data type and API definitions - i.e. explicit 
slab.h inclusion in the .c file.

I'm leaning towards that solution of avoiding combo .h files - even if in the 
slab.h case the concept causes us to touch quite a few .c files.

As long as it's expected to cause no shock we can do it in one big atomic 
risk-free commit: which just adds the #include slab.h's to the .c files, 
nothing else.

Look at the advantages:

 - (slightly) sped up kbuild

 - it would be immediately obvious in the future which .c file makes use of 
   SLAB facilities. We wouldnt have to guess or go to object file analysis to 
   figure out any 'true' usage.

 - [ it would be trivial in the future to actually _remove_ stale #include
     files. When there's no indirect inclusion of facilities then the lack of 
     usage can be decided based on API usage patterns in the .c files. ]

It's a much cleaner end result IMHO (which also happens to be faster to build) 
- and slab.h is definitely the worst-case, so we should not wimp out just due 
to that difficulty.

Thanks,

	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/