linux-kernel - Re: [PATCH] mux-core: make it explicitly non-modular

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] [day] [month] [year] [list]

Message-ID: <20170309223132.GJ7825@windriver.com>
Date:   Thu, 9 Mar 2017 17:31:32 -0500
From:   Paul Gortmaker <paul.gortmaker@...driver.com>
To:     Peter Rosin <peda@...ntia.se>
CC:     <linux-kernel@...r.kernel.org>, Jonathan Cameron <jic23@...nel.org>
Subject: Re: [PATCH] mux-core: make it explicitly non-modular

[Re: [PATCH] mux-core: make it explicitly non-modular] On 09/03/2017 (Thu 13:01) Peter Rosin wrote:

> On 2017-03-09 10:39, Peter Rosin wrote:
> 
> *snip* *snip*
> 
> >> Per the above use case (minimal vmlinux) the unload isn't so important,
> >> and in many cases it may be racy or simply not make sense.  If that is
> >> the case, you don't need to provide a module_exit, and in the past I
> >> think we used to bump the module use count at a successful load to
> >> prevent unloading ; there might be a more elegant method now; google is
> >> your friend here.  Also, I don't think name reuse/confusion is an issue.
> > 
> > Ok, I thought it all boiled down to making the mux-core Kconfig a tristate
> > option and changing subsys_initcall(...) to module_init(...).
> > 
> > But if I do that, I cannot be sure that the mux-core has been initialized
> > before drivers and clients start to use it in the non-modular case (if
> > things are modules, the dependencies should ensure that the mux-core is
> > loaded/initialized before any users are loaded). But there is no
> > topological sorting going on for ordering init calls in the non-modular
> > case.
> > 
> > In short, I get:
> > 
> > WARNING: CPU: 0 PID: 1 at drivers/base/class.c:438: class_find_device+0xac/0xb8
> > class_find_device called for class 'mux' before it was initialized

[...]

> > 
> > So, it appears that I also have to determine if the core has been
> > initialized in all its entry points and return -EPROBE_DEFER (or something)
> > when not. I suppose I could instead initialize on-demand, but that seems
> > more difficult the do without races...
> > 
> > Am I missing something?
> 
> I did some digging and e.g. drivers/uwb was moved before drivers/usb in
> commit ae5d82cb8d60 ("uwb: build UWB before USB/WUSB") to resolve what
> appears to be a similar situation. I suppose I could just move mux up in
> drivers/Makefile so that it is before both i2c and iio.

So, you can "cheat" and leave it as subsys_initcall (and add a comment
why it is) and it will be subsys_initcall when built-in and module_init
when modular -- that should work too, and if you look around you'll
probably see many other existing instances of that going on.

init.h
   #ifndef MODULE
   [...]
   #define subsys_initcall(fn)             __define_initcall(fn, 4)

module.h
   #else /* MODULE */
   [...]
   #define subsys_initcall(fn)              module_init(fn)

Paul.
--

> 
> Cheers,
> peda
>