linux-kernel - Re: regulator: core: Request GPIO before creating sysfs entries

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: <20160223143420.GB19954@box2.japko.eu>
Date:	Tue, 23 Feb 2016 15:34:21 +0100
From:	Krzysztof Adamski <krzysztof.adamski@...to.com>
To:	Jon Hunter <jonathanh@...dia.com>
Cc:	Mark Brown <broonie@...nel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: regulator: core: Request GPIO before creating sysfs entries

On Tue, Feb 23, 2016 at 02:15:21PM +0000, Jon Hunter wrote:
>Hi Krzysztof,
>
>On 23/02/16 13:56, Krzysztof Adamski wrote:
>> On Tue, Feb 23, 2016 at 01:22:38PM +0000, Jon Hunter wrote:
>>> Hi Mark, Krzysztof,
>>>
>>> It appears that commit daad134d6649 ("regulator: core: Request GPIO
>>> before creating sysfs entries") breaks boot on tegra124-nyan-big in
>>> -next today.
>>>
>>> Looking at the change, it does not appear that the exit path has been
>>> updated correctly and so if a regulator is deferred then there is a
>>> crash in the exit path. I am not sure that there is a simple way to
>>> workaround this because of fix from commit 53032dafc6b9 ("regulator
>>> core: fix double-free in regulator_register() error path") unless we
>>> move regulator_ena_gpio_free() into regulator_dev_release().
>>
>> Hi Jon,
>>
>> You are totally right about the problem but I can't see why changing
>> "goto wash" to "goto clean" in error path of regulator_ena_gpio_request
>> is not enough. What am I missing?
>
>So device_unregister() will call regulator_dev_release() which will free
>rdev (see commit 53032dafc6b9). However, rdev is needed by
>regulator_ena_gpio_free() and therefore, we need to call
>regulator_ena_gpio_free() before we call device_unregister(). So
>swapping the order will cause other problems.
>
>One possibility would be to move regulator_ena_gpio_free() into
>regulator_dev_release(). If did we could remove the
>regulator_ena_gpio_free() from regulator_unregister(). However, I have
>not looked at that in great detail. May be Mark can comment if that
>would be ok.

But in case of regulator_ena_gpio_free() failure, we shouldn't call 
device_unregister() at all, since it was not yet registered and that is 
exactly what "clean" does.

Best regards,
Krzysztof Adamski