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: <4942246.OV4Wx5bFTl@n9w6sw14>
Date: Thu, 13 Mar 2025 08:36:45 +0100
From: Christian Eggers <ceggers@...i.de>
To: Doug Anderson <dianders@...omium.org>
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 Doug,

On Thursday, 13 March 2025, 01:42:14 CET, Doug Anderson wrote:
> 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.

actually I also tested successfully without synchronous probing (only with checking
that the dummy regulator has been probed) and this also worked fine (just to
be sure, I also added a temporary delay in the dummy's probe routine).  But as
the dummy regulator doesn't rely on slow I/O, I felt that synchronous probing
makes more sense than "busy-waiting" for it.

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

regards,
Christian