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]

Message-ID: <20100316081623.GF18448@elte.hu>
Date:	Tue, 16 Mar 2010 09:16:23 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Tejun Heo <tj@...nel.org>,
	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>
Subject: Re: [RFC] remove implicit slab.h inclusion from percpu.h

* Alexey Dobriyan <adobriyan@...il.com> wrote:

> On Tue, Mar 16, 2010 at 8:17 AM, Ingo Molnar <mingo@...e.hu> wrote:
> > Also, why should we make this opt-in and expose a wide range of configs to
> > build breakages?
> 
> Because we want to #include less, not the same amount.
> 
> > A more gradual approach would be to write a simple script
> > that adds a slab.h include to all .c's that include percpu.h, directly or
> > indirectly.
> 
> As a defensive measure, one can explicitly add slab.h to every file which 
> uses kmalloc/kfree.
> 
> But, who cares, since one still has to compile test regardless.

Firstly, generating #include slab.h lines in .c files based on actual API 
usage is _good_, pretty much unconditionally so. See my previous mail for the 
list of advantages. Even if it increases the number of #include lines 
temporarily.

Secondly, the point in scripting is to intentionally over-shoot the target, as 
compile testing (especially if it's only modconfig), will only cover so much 
and _if we can_ we should avoid breakage.

That way the over-shooting will cover cases you are not able (or did not 
happen to) build-test. It's much better to have temporarily more include lines 
than have fewer and break the build. We'll need a #include line reduction 
mechanism in any case as APIs frequently get unused and #include lines get 
amassed in .c files.

Thirdly, as for build testing only, see for example a sched.h include file 
cleanup _you_ did in the past, which, despite your build testing, broke quite 
some code:

 commit 86ae13b006e48959981248493efd3ff4b2828b3d
 Author: Ingo Molnar <mingo@...e.hu>
 Date:   Mon Oct 12 16:22:46 2009 +0200

    headers: Fix build after <linux/sched.h> removal

    Commit d43c36dc6b357fa1806800f18aa30123c747a6d1 ("headers: remove
    sched.h from interrupt.h") left some build errors in some configurations
    due to drivers having depended on getting header files "accidentally".

    Signed-off-by: Ingo Molnar <mingo@...e.hu>
    [ Combined several one-liners from Ingo into one single patch  - Linus ]
    Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>

 drivers/char/genrtc.c        |    1 +
 drivers/char/rtc.c           |    1 +
 drivers/char/sonypi.c        |    1 +
 drivers/net/wan/c101.c       |    1 +
 drivers/net/wan/n2.c         |    1 +
 drivers/net/wan/pci200syn.c  |    1 +
 drivers/pci/hotplug/cpqphp.h |    1 +
 7 files changed, 7 insertions(+), 0 deletions(-)

I dont mind the occasional breakage, but avoidable bugs spread out in the tree 
can be a real PITA to testers.

I remember it, that imperfect conversion kept me busy chasing trivial build 
bugs for most of the day, because they would pop up with different config 
dependencies so they had to be addressed separately. (so i created 7 separate 
fixes as the day progressed - and that in a busy period of the cycle so i 
certainly didnt have a day to waste voluntarily)

Note that that d43c36dc patch of yours wasnt in linux-next IIRC, so you didnt 
even get basic build coverage. I have no problem with fixing more difficult 
bugs or with fixing the occasional silly oversight (that's the _point_ of 
developing the kernel after all), but i have a problem with reasonably 
avoidable bugs.

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/