linux-kernel - Re: [PATCH v2 1/2] regulator: dummy: force synchronous probing

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: <CAD=FV=UBUN+DERvSdZn67FUvyT+U_CNJs0HUdHooSZSK2F6Nsw@mail.gmail.com>
Date: Wed, 12 Mar 2025 17:42:14 -0700
From: Doug Anderson <dianders@...omium.org>
To: Christian Eggers <ceggers@...i.de>
Cc: Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, 
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/2] regulator: dummy: force synchronous probing

Hi,

On Tue, Mar 11, 2025 at 2:18 AM Christian Eggers <ceggers@...i.de> wrote:
>
> Sometimes I get a NULL pointer dereference at boot time in kobject_get()
> with the following call stack:
>
> anatop_regulator_probe()
>  devm_regulator_register()
>   regulator_register()
>    regulator_resolve_supply()
>     kobject_get()
>
> By placing some extra BUG_ON() statements I could verify that this is
> raised because probing of the 'dummy' regulator driver is not completed
> ('dummy_regulator_rdev' is still NULL).
>
> In the JTAG debugger I can see that dummy_regulator_probe() and
> anatop_regulator_probe() can be run by different kernel threads
> (kworker/u4:*).  I haven't further investigated whether this can be
> changed or if there are other possibilities to force synchronization
> between these two probe routines.  On the other hand I don't expect much
> boot time penalty by probing the 'dummy' regulator synchronously.
>
> Cc: stable@...r.kernel.org
> Fixes: 259b93b21a9f ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14")
> Signed-off-by: Christian Eggers <ceggers@...i.de>
> ---
> v2:
> - no changes
>
>  drivers/regulator/dummy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Not that it should really hurt, but do we need both commit
cfaf53cb472e ("regulator: check that dummy regulator has been probed
before using it") and this one? It seems like commit cfaf53cb472e
("regulator: check that dummy regulator has been probed before using
it") would be sufficient and we don't really need to force the
regulator to synchronous probing.

...not that I expect the dummy probing synchronously to be a big deal,
I just want to make sure I understand.

-Doug