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: <20081001085219.GB25009@elte.hu>
Date:	Wed, 1 Oct 2008 10:52:19 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Rolf Eike Beer <eike-kernel@...tec.de>
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()


* Rolf Eike Beer <eike-kernel@...tec.de> wrote:

> Ingo Molnar wrote:
> > * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> > > Dang.
> > >
> > > I guess we'll have to bite the bullet some day and actually create
> > > some explicit topological ordering of initcalls rather than depend on
> > > the initcall levels and link order. That is one particular complexity
> > > I've tried to avoid. But the subtlety of the current ordering is
> > > certainly not at all good either.
> >
> > incidentally, i've been talking to Arjan about this recently in context
> > of the CONFIG_FASTBOOT feature. Because, as a side-effect, in the long
> > run, once the dependencies between initcalls fan out in a more natural
> > way, with explicit initcall ordering we'll also be able to boot a bit
> > faster and a bit more parallel.
> >
> >  [ but performance is far less important than robustness, so this idea
> >    was on the backburner. ]
> >
> > and i think on the conceptual level initcall levels and implicit
> > ordering are bad in the same way SPL and IPL based locking is worse than
> > real, explicit spinlocks.
> >
> > i think the topological ordering should not be just an extension of the
> > current hardcoded initcall levels, but it should be symbol space based:
> > i.e. an initcall should depend not on some kind of artificial enum, but
> > it should depend on _another initcall_. (a list of initcalls more
> > generally)
> >
> > so instead of the current hardcoded levels:
> >
> >   core_initcall(sysctl_init);
> >
> > we could have natural constructs like:
> >
> >   initcall_depends_on(sysctl_init, securityfs_init);
> >   initcall_depends_on(sock_init, sysctl_init)
> >
> > where we create explicit dependencies between actual initcalls just by
> > listing their dependencies. In many cases we could express dependencies
> > in a natural way:
> >
> >   initcall_depends_on(some_subsys_init, kmem_cache_init);
> >   initcall_depends_on(some_subsys_init, sched_init);
> >
> > which would express the fact that some_subsys_init() must execute after
> > kmem_cache_init() and after sched_init().
> >
> > Each initcall is associated with an 'initcall descriptor', which shows
> > which other initcalls this initcall depend on, and whether the initcall
> > has been executed already.
> >
> > during bootup the initcall engine would parse the graph and would
> > execute all the 'leaf' initcalls, and would complete the graph
> > gradually.
> >
> > ( More details: we'd have a number of compatibility and convenience
> >   symbols as well - well-known initialization stages for various
> >   customary phases of bootup.
> >
> >   And at link time we could detect circular dependencies. )
> >
> > So ... this scheme looks elegant to me, but maybe it is overdesigned?
> 
> Why calculate this at boot time? Do you expect this to change between 
> bootups?

yes, we could indeed map it statically to a single-threaded bootup 
sequence at build time. That is more reproducible, more deterministic, 
etc.

[ What i was thinking about the most generic long-run approach: each CPU 
  processing initcalls in parallel. Then the initcall graph is processed
  in parallel and the ordering and speed of execution (and the grade of
  completion) depends on the number of CPUs, their speed and other
  factors, etc.

  But it would be madness to combine such a facility with the current
  fragile single-threaded boot code. ]

	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/