linux-kernel - Re: mmotm 2009-02-02-17-12 uploaded (x86/nopmd etc.)

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: <20090204200846.GF22608@elte.hu>
Date:	Wed, 4 Feb 2009 21:08:46 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	jeremy@...p.org, jaswinderrajput@...il.com,
	randy.dunlap@...cle.com, linux-kernel@...r.kernel.org,
	x86@...nel.org, righi.andrea@...il.com
Subject: Re: mmotm 2009-02-02-17-12 uploaded (x86/nopmd etc.)


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

> > > This is getting painful.
> > 
> > the include file spaghetti is ... interesting there, and it's historic.
> > 
> > I could blame it on highmem, PAE or paravirt - but i'll only blame it on 
> > paravirt for now because those developers are still around! ;-)
> > 
> > Jeremy, any ideas how to reduce the historic dependency mess in that area?
> > I think we should go on three routes at once:
> > 
> >  - agressive splitup and separation of type definitions from method
> >    declaration (+ inline definitions). The spinlock_types.h / spinlock.h 
> >    splitup was really nice in solving such dependency problems.
> 
> I like this one.  The mixing up of declare-something with use-something
> is often the source of our woes.

yes. I mapped this problem area once and this is how the include file 
spaghetti gets generated in practice:

  - type A gets declared
  - type A gets _used_ in the same file in an inline method, BUT,

      that usage also brings in instantiated use of type X1, X2 and X3.

if all types are declared like that everywhere, it can be seen (and it's a 
mathematical certainty) that the only conflict-free way of doing this is to:

  - initially add random #include lines to bring in type X1, X2 and X3. 
    Which brings in recursive dependencies from those X1 X2 and X3 files.

  - when the stuff hits the fan then folks are in a big mess already and 
    only a deep restructuring could gets them out of it - which they rarely 
    do in an iterative environment. So they work it around iteratively: 
    instead of new nice inline methods [which we really prefer] they delay 
    all the 'usage' instantiation to .c file via the use of CPP macros 
    [which we hate because they hide bugs and cause bugs].

Repeat that process for 15 years, on a 10 MLOC kernel with 1 MLOC headers 
spread out in 10,000+ header files and you can see how it builds up to a big 
pile of goo.

In fact i'm surprised it's not worse than it is - a mitigating factor are 
uninlining efforts which happen to have the side-effect of reducing the 
spaghetti.

The only structural change that would solve this situation is a tool that 
enforces that type definitions and methods related to a type should never 
mix. We are far from being able to enforce anything like that.

	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/