linux-kernel - Re: [patch 2/2] PNP: don't check disabled PCI BARs for conflicts in quirk_system_pci

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: <20081001082603.GA31009@elte.hu>
Date:	Wed, 1 Oct 2008 10:26:03 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Grant Grundler <grundler@...isc-linux.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Rene Herman <rene.herman@...access.nl>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Len Brown <lenb@...nel.org>, Frans Pop <elendil@...net.nl>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org,
	Adam Belay <abelay@....edu>, Avuton Olrich <avuton@...il.com>,
	Karl Bellve <karl.bellve@...ssmed.edu>,
	Willem Riede <wriede@...de.org>,
	Matthew Hall <mhall@...omputing.net>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: [patch 2/2] PNP: don't check disabled PCI BARs for conflicts
	in quirk_system_pci_resources()

* Grant Grundler <grundler@...isc-linux.org> wrote:

> On Tue, Sep 30, 2008 at 12:51:07PM -0700, Linus Torvalds wrote:
> ....
> > But I think we could add a separate notion of a dependancy point, and have 
> > a setup where we describe "initcall X needs to happen before point A" and 
> > "initcall Z needs to happen after point A".
> > 
> > And then we can create a separate set of these dependency points, so that 
> > X and Y don't have to know about each other, they just have to have some 
> > knowledge about some common synchronization point - one that exists 
> > regardless of whether X or Y are even compiled in!
> 
> We already do this today. :)
> Definitions are in include/linux/init.h.
> Point A would be "early" ("run before initialing SMP")
> The rest could use better definitions and AFAICT aren't that much better
> than being named "Point B".

the structural problem with the current level-based initcall design is 
that the current dependencies are implicit (not spelled out clearly 
anywhere in the source code), and bugs in them are often fixed by 
experimenting around (seeing whether it breaks), not by design.

Changing it is a ton of work, and the risks of touching that code might 
eclipse any (often marginal) advantages a new scheme has. Today boot 
code runs only once and it is one of the most under-tested pieces of 
kernel code. Boot code's quality and robustness is at least 1 order of 
magnitude worse than regular kernel code.

But to play the devil's advocate: users have so many problems with weird 
races in boot code today _already_, wouldnt it be better to expose boot 
code to more variations, to put it under environmental pressure that 
ultimately improves its quality?

Init code is often reused during suspend/resume, so by introducing more 
flexibility into initcalls maybe we create enough pressure to fix them 
when it's far easier to fix them. (after bootup - fixing after-resume 
bugs is much harder because often the console is turned off and no 
significant BIOS code ran.)

Today moving an initcall to another level has unknown effects and 
nothing warns about broken dependencies but a bootup crash (often only 
triggering under a specific .config), or a non-working device or some 
other regression.

That is rather fragile and i doubt anyone can argue the opposite.

The question of whether explicit dependencies are better is another 
question and up to debate:

in the long run it is _IMHO_ more robust to express explicit 
dependencies close to the init functions, in the source code:

  initcall_depends_on(this_driver, memory_init);
  initcall_depends_on(this_driver, io_resources_init);

than to rely on the implicit (and undocumented and often forgotten) 
dependencies we have currently.

For example ordering an initcall to after PNP init would be trivial, 
we'd add this to the init dependency list:

  initcall_depends_on(this_driver, pnp_init);

With the current scheme we have to find some other integer 'level' and 
hope that moving this initcall to that new level does not break other, 
implicit dependencies.

And note that once we start doing explicit dependencies, we could 
automate much of it: if a piece of .o uses a set of symbols that makes 
it rather clear which subsystems it has to rely on. Say it uses 
kmalloc() then it should depend on memory_init() done.

	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/