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

[Christian Eggers]

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@xxxxxxx> 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@xxxxxxxxxxxxxxx
> > Fixes: 259b93b21a9f ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14")
> > Signed-off-by: Christian Eggers <ceggers@xxxxxxx>
> > ---
> > 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