linux-kernel - Re: [PATCH 04/14] init: deps: order network interfaces by link order

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: <20151017185509.GA28601@kroah.com>
Date:	Sat, 17 Oct 2015 11:55:09 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Alexander Holler <holler@...oftware.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Russell King <linux@....linux.org.uk>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH 04/14] init: deps: order network interfaces by link order

On Sat, Oct 17, 2015 at 08:37:35PM +0200, Alexander Holler wrote:
> I'm making dependencies the only ordering for annotated initcalls.
> 
> Otherwise it's impossible to call initcalls in parallel.

We don't ever want to call initcalls in parallel, unless they can
properly handle it.  All drivers can tell the driver core to use
parallel probing if they know they can handle it.  See 'enum probe_type'
for this.

Trying to call initcalls or driver probes in parallel blindly has been
proven to both take a longer amount of time, and cause problems for
drivers that aren't expecting it.  The research on this was done years
ago when people were starting to work on booting quicker, and the end
result is what we have now where drivers that know they can handle this,
can tell the core to let them probe in this manner.

The outcome of this work is the sub-second boot time we have today.  If
your systems are taking longer to boot, then please look into the
drivers that are causing this, that is where the real issue is, not in
the core of the kernel.

thanks,

greg k-h
--
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/