linux-kernel - Re: [PATCH] regulator: core: Take lock before applying system load

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: <20190218183944.GH10794@sirena.org.uk>
Date:   Mon, 18 Feb 2019 18:39:44 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Niklas Cassel <niklas.cassel@...aro.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: core: Take lock before applying system load

On Fri, Feb 15, 2019 at 11:55:33AM +0100, Niklas Cassel wrote:
> Take the regulator lock before applying system load.
> 
> Fixes the following lockdep splat:
> 
> [    5.583581] WARNING: CPU: 1 PID: 16 at drivers/regulator/core.c:925 drms_uA_update+0x114/0x360
> [    5.588467] Modules linked in:
> [    5.596833] CPU: 1 PID: 16 Comm: kworker/1:0 Not tainted 5.0.0-rc6-next-20190213-00002-g0fce66ab480f #18

Please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative then it's
usually better to pull out the relevant sections.

>  		 * We'll only apply the initial system load if an
>  		 * initial mode wasn't specified.
>  		 */
> +		regulator_lock(rdev);
>  		drms_uA_update(rdev);
> +		regulator_unlock(rdev);

This is correct in that it will shut up the warning but we're not
supposed to need locks at this point as the regulator is in the process
of being registered so there should be no possibility of concurrent
access.  Since I can't see a sensible way to conditionally assert that
the lock is held we're probably better off just removing the annotation
since it's no longer valid.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)