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: <200809302206.11391.eike-kernel@sf-tec.de>
Date:	Tue, 30 Sep 2008 22:05:44 +0200
From:	Rolf Eike Beer <eike-kernel@...tec.de>
To:	Ingo Molnar <mingo@...e.hu>
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()

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?

Eike

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)