linux-kernel - Re: [patch] drivers: wait for threaded probes between initcall levels

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: <20061028060833.GC5560@colo.lackof.org>
Date:	Sat, 28 Oct 2006 00:08:33 -0600
From:	Grant Grundler <grundler@...isc-linux.org>
To:	Andrew Morton <akpm@...l.org>
Cc:	Grant Grundler <grundler@...isc-linux.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Pavel Machek <pavel@....cz>, Greg KH <greg@...ah.com>,
	Stephen Hemminger <shemminger@...l.org>,
	Matthew Wilcox <matthew@....cx>, Adrian Bunk <bunk@...sta.de>,
	Linus Torvalds <torvalds@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [patch] drivers: wait for threaded probes between initcall levels

On Fri, Oct 27, 2006 at 10:19:25PM -0700, Andrew Morton wrote:
> > > It would be nice to express those dependencies in some clearer and less
> > > fragile manner than link order.  I guess finer-grained initcall levels
> > > would do that, but it doesn't scale very well.
> > 
> > Would making use of depmod data be a step in the right direction?
> 
> Nope.  The linkage-order problem is by definition applicable to
> linked-into-vmlinux code, not to modules.

But wouldn't the same concept apply to non-module symbols that
are tagged with EXPORT_SYMBOL()?
Maybe I'm just showing my ignorance about kernel linking here...

> > ie nic driver calls extern function (e.g. pci_enable_device())
> > and therefore must depend on module which provides that function.
> > 
> > My guess is this probably isn't 100% sufficient to replace all initcall
> > levels.  But likely sufficient within a given initcall level.
> > My main concern are circular dependencies (which are rare).
> 
> The simplest implementation of "A needs B to have run" is for A to simply
> call B, and B arranges to not allow itself to be run more than once.

Yes. we already have code like this in the kernel.
e.g. superio support in drivers/parisc.

> But that doesn't work in the case "A needs B to be run, but only if B is
> present".

I was thinking of "A is present and calls into module B, therefore B needs
to init first". In this case, A won't care if B is really present or not.
A depends on B to figure that out at runtime. If B is not configured into
the kernel, A won't ever call B since the "function" will be a NOP.
(e.g. #ifndef CONFIG_B/#define b_service() /* NOP */ /#endif)
 

>  Resolving this one would require something like a fancy
> "synchronisation object" against which dependers and dependees can register
> interest, and a core engine which takes care of the case where a depender
> registers against something which no dependees have registered.

I guess I was wondering if the kernel link step could use symbol information
in a similar way the kernel module autoloader uses depmod info. But other
parts of the kernel might not be as modular as most of the IO subsystems
are.

I'm not looking for ways to make the process more complicated for
the people maintaining code. Keeping the registrations of dependencies
up-to-date manually would just be another PITA.

...
> > I thought parallel PCI and SCSI probing on system with multiple NICs and
> > "SCSI" storage requires udev to create devices with consistent naming.
> 
> For some reason people get upset when we rename all their devices.  They're
> a humourless lot.

Hey! I resemble that remark! ;)

(yeah, I've been a victim of that problem way too many times.)

thanks,
grant
-
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/