linux-kernel - Re: [PATCH] gpio: Do not accept gpio chip additions before gpiolib initialization

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: <56FD1C8E.60405@roeck-us.net>
Date:	Thu, 31 Mar 2016 05:48:14 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Alexandre Courbot <gnurou@...il.com>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpio: Do not accept gpio chip additions before gpiolib
 initialization

On 03/30/2016 10:57 PM, Alexandre Courbot wrote:
> On Wed, Mar 30, 2016 at 6:16 PM, Guenter Roeck <linux@...ck-us.net> wrote:
>> On 03/30/2016 01:37 AM, Alexandre Courbot wrote:
>>>
>>> On Wed, Mar 30, 2016 at 3:20 AM, Guenter Roeck <linux@...ck-us.net> wrote:
>>>>
>>>> Since commit ff2b13592299 ("gpio: make the gpiochip a real device"),
>>>> attempts to add a gpio chip prior to gpiolib initialization cause the
>>>> system to crash. Dump a warning to the console and return an error
>>>> if the situation is encountered.
>>>
>>>
>>> Mmm I see the problem but this could seriously delay the availability
>>> of some GPIOs that are useful for early system boot.
>>>
>>> I have not followed the GPIO device patches as closely as I should
>>> have, but shouldn't you be able to register a GPIO chip without
>>> immediately presenting it to user-space, for internal kernel needs? If
>>> gpiolib is not initialized, then device-related operations would be
>>> skipped, and gpiolib_dev_init() could then parse the list of
>>> registered chips and fix them up when it gets called.
>>>
>>> Again, I'm speaking without real knowledge here, but that pattern
>>> seems more resilent to me.
>>>
>> You are absolutely right, but my knowledge of gpiolib is not good enough
>> to make that change. See this as a band-gap; it is better than just
>> crashing.
>
> Actually, the following may be simpler:
>
> Why not add a check in gpiochip_add_data() that will directly call
> gpiolib_dev_init() if required? Then gpiolib_dev_init() could also
> check whether it has already been called in that context and become a
> no-op for when it is later called from core_initcall. Is there
> anything that would prevents this from being a viable fix?
>
That was my first solution. Unfortunately, it doesn't work. It appears
that the calls made by gpiolib_dev_init() have dependencies themselves.
Though maybe I messed up - feel free to try yourself.

As mentioned in the other thread, I started looking into the solution
you suggested above. It should work, but it will take (me) a while
to implement it. Until then, guess we'll see more breakage.

Guenter