linux-kernel - Re: [PATCH 0/14] init: deps: dependency based (parallelized) init

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]

Date:	Sat, 17 Oct 2015 10:44:57 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Alexander Holler <holler@...oftware.de>
Cc:	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Russell King <linux@....linux.org.uk>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH 0/14] init: deps: dependency based (parallelized) init

On Sat, Oct 17, 2015 at 07:14:13PM +0200, Alexander Holler wrote:
> Hello,
> 
> here is the newest version of my patches to use a dependency based
> initialization order. It now works without DT too.
> 
> Background:
> 
> Currently initcalls are ordered by some levels and the link order. This
> means whenever a file is renamed, changes directory or a Makefile is
> modified the order with which initcalls are called might change. This
> might result in problems. Furthermore, the required dependencies are
> often not documented, sometimes there are comments in the source or in a
> commit message, but most often the knowledge why a specific initcall
> belongs to a specific initcall level isn't obvious without carefully
> examing he source. And initcalls are used by drivers and subsystems, and
> the count of both have grown quiet a lot in the last years. So it's
> rather difficult to maintain a proper link order.

Files move around very rarely, is this really an issue?

> Another problem is that the link order can't be modified dynamically at
> boot time to include dependencies dictated by the hardware. To circumvent
> this, a brute-force trial-and-error mechanism called deferred probes has
> been introduced, but this approach, while beeing KISS, has its own
> problems.

What problems does deferred probing have?  Why not just fix that if
there is issues with it, as it was supposed to solve this issue without
needing to annotate anything.

> To solve these problems I've written patches to use a topological sort at
> boot time which uses dependencies to calculate the order with which
> initcalls are called.
> 
> Why? What are the benefits (assuming correct dependencies are available)?
> 
> - It offers a clear in-source documentation for dependencies between
>   initcalls.
> - It is robust in regard to file or directory name changes and changes in
>   a Makefile.
> - If enabled, the order with which drivers for interfaces are called
>   (e.g. network interfaces, hard disks), can be defined independent of
>   the link order. These might result in more stable interface names or
>   numbers.
> - If enabled, it makes the the deferred probes obsolete, which might
>   result in faster boot times.
> - If enabled, it is possible to call initcalls in parallel. E.g. the
>   shipped kernel for Fedora 21 (4.1.7-100.fc21.x86_64) contains around
>   560 initcalls. These are all called in series. Also some of them use
>   asynchronous stuff by themself, most don't do.

But that shipped kernel boots to X in less than 2 seconds, so there
isn't really a speed issue here, right?

> Drawbacks:
> 
> - It requires a small amount of time to calculate the order a boot time.
>   But this time is most often smaller than the time saved by using
>   multiple cores to call initcalls or by not needing deferred probes.

How much time is needed?

> - Dependencies are required. For everything which can be build as a
>   module, looking at modules.dep might give some pointers. Looking at
>   the help from menuconfig also might give some pointers. But in the
>   end, the most preferable way would be if maintainers or other people
>   which have a deeper knowledge about the source and functionality
>   would add the dependencies.

How will a "normal" driver author figure out what those dependancies are
in order to be able to write them down?  That's my biggest objection
here, I have no idea how to add these, nor how to properly review such a
submission.  What about systems that have different ordering/dependancy
requirements for the same drivers due to different ways the hardware is
hooked up?  That is not going to work well here, unless I'm missing
something.

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/