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: <20170814053510.GI31819@dragon>
Date:   Mon, 14 Aug 2017 13:35:12 +0800
From:   Shawn Guo <shawnguo@...nel.org>
To:     Stefan Agner <stefan@...er.ch>, arm@...nel.org
Cc:     kernel@...gutronix.de, Fabio Estevam <fabio.estevam@....com>,
        Andrey Smirnov <andrew.smirnov@...il.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] soc: imx: gpcv2: fix regulator deferred probe

On Sun, Aug 13, 2017 at 10:12:13PM -0700, Stefan Agner wrote:
> Hi Shawn,
> 
> On 2017-08-04 20:13, Shawn Guo wrote:
> > On Wed, Aug 02, 2017 at 12:51:29PM -0700, Stefan Agner wrote:
> >> If a regulator requests a deferred probe, the power domain gets
> >> initialized twice. This leads to a list double add (without
> >> list debugging the kernel hangs due to the double add later):
> >>
> >>   WARNING: CPU: 0 PID: 19 at lib/list_debug.c:31 __list_add_valid+0xbc/0xc4
> >>   list_add double add: new=c1229754, prev=c12383b4, next=c1229754.
> >>
> >> Initialize the power domain after we get the regulator. Also do
> >> not print an error in case the regulator defers probing.
> >>
> >> Cc: Fabio Estevam <fabio.estevam@....com>
> >> Cc: Andrey Smirnov <andrew.smirnov@...il.com>
> >> Cc: linux-arm-kernel@...ts.infradead.org
> >> Cc: linux-kernel@...r.kernel.org
> >> Fixes: 03aa12629fc4 ("soc: imx: Add GPCv2 power gating driver")
> >> Signed-off-by: Stefan Agner <stefan@...er.ch>
> > 
> > Applied, thanks.
> 
> As of 4.13-rc5 this did not make it upstream yet, I guess still on its
> way?

Yes, Stefan. It's on the way to arm-soc [1], but not yet responded.

Shawn

[1] https://www.spinics.net/lists/arm-kernel/msg598634.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ