linux-kernel - Re: MMC/regulator boot hang in -next

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:	Mon, 2 Nov 2015 14:03:14 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Bjorn Andersson <bjorn.andersson@...ymobile.com>
Cc:	Sascha Hauer <s.hauer@...gutronix.de>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>
Subject: Re: MMC/regulator boot hang in -next

On Mon, Nov 2, 2015 at 12:46 PM, Bjorn Andersson
<bjorn.andersson@...ymobile.com> wrote:
> On Mon 02 Nov 11:57 PST 2015, John Stultz wrote:
>
>> Trying to move my nexus7 work to -next, I started seeing boot time
>> hangs. Enabling some debug options provided with a lockdep spew.
>>
>> Reverting "regulator: core: Propagate voltage changes to supply
>> regulators" -  fc42112c0eaa avoids the hang, but I still see lockdep
>> noise.
>>
>> Full log of -next based tree without any reverts follows:
>
> It sure does lock like a deadlock to me. Can you figure out which
> regulator we're talking about here? And confirm that this is 8064 we're
> talking about

So it looks like we're setting the voltage on lvs1, which then calls
get_voltage() on s4. At that point the lockdep spew hits.

But as Mark noted *this* spew looks like a false positive, but I
suspect lockdep is then disabled and can't detect the real hang
happens shortly afterwards.

The key bit needed to revert to get things booting for me  in
fc42112c0eaa ("regulator: core: Propagate voltage changes to supply
regulators") is (sorry, copy pasted text here, apologies for the
whitespace damage):
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2952,11 +2952,12 @@ int regulator_set_voltage(struct regulator
*regulator, int min_uV, int max_uV)
 {
        int ret = 0;

-       regulator_lock_supply(regulator->rdev);
+       mutex_lock(&regulator->rdev->mutex);

        ret = regulator_set_voltage_unlocked(regulator, min_uV, max_uV);

-       regulator_unlock_supply(regulator->rdev);
+       mutex_unlock(&regulator->rdev->mutex);

        return ret;
 }


Might the problem be here that we lock the supply in set_voltage, then
if we call _regulator_get_voltage on the supply later, we try to grab
the same lock and we're stuck?

thanks
-john
--
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/