Re: [PATCH 0/5] platform/chrome: Fix a race when probing drivers

[Tzung-Bi Shih <tzungbi@kernel.org>]

On Fri, Aug 29, 2025 at 08:50:01PM +0800, Tzung-Bi Shih wrote:
> On Fri, Aug 29, 2025 at 11:28:55AM +0000, Dmitry Torokhov wrote:
> > On Thu, Aug 28, 2025 at 08:35:56AM +0000, Tzung-Bi Shih wrote:
> > > A race is observed when cros_ec_lpc and cros-ec-keyb are all built as
> > > modules.  cros_ec_lpc is cros-ec-keyb's parent.  However, they can be
> > > probed at the same time.
> > > 
> > > Example:
> > > 
> > > + -----------------------------------------------------------------+
> > > | Some init process (e.g. udevd) | deferred_probe_work_func worker |
> > > + -----------------------------------------------------------------+
> > > | Probe cros-ec-keyb.            |                                 |
> > > | - Decide to defer[1].          |                                 |
> > > |                                | A device bound to a driver[2].  |
> > > | Probe cros_ec_lpc.             |                                 |
> > > | - Init the struct[3].          |                                 |
> > > |                                | Retry cros-ec-keyb from the     |
> > > |                                | deferred list[4].               |
> > > |                                | - Won't defer again as [3].     |
> > > |                                | - Access uninitialized data in  |
> > > |                                |   the struct.                   |
> > > | - Register the device.         |                                 |
> > > + -----------------------------------------------------------------+
> > > 
> > > [1] https://elixir.bootlin.com/linux/v6.16/source/drivers/input/keyboard/cros_ec_keyb.c#L707
> > > [2] https://elixir.bootlin.com/linux/v6.16/source/drivers/base/dd.c#L405
> > > [3] https://elixir.bootlin.com/linux/v6.16/source/drivers/platform/chrome/cros_ec_lpc.c#L644
> > > [4] https://elixir.bootlin.com/linux/v6.16/source/drivers/base/dd.c#L418
> > > 
> > > Note that the device link[5] can't help as in the observed environment,
> > > the devices are already added via device_add()[6].
> > > 
> > > [5] https://www.kernel.org/doc/html/latest/driver-api/device_link.html#usage
> > > [6] https://elixir.bootlin.com/linux/v6.16/source/drivers/acpi/acpi_platform.c#L177
> > > 
> > > The series fixes the issue by ensuring the struct is ready for accessing
> > > before continuing to probe cros-ec-keyb.
> > 
> > Why is the keyboard platform device instantiated before the transport
> > (cros_ec_lpc) is done initializing? I think this is the root of the
> > issue...
> 
> I may misunderstand but it seems to me:
> 
> - The ACPI bus enumerated and instantiated the platform devices[6] first.
> 
> - The keyboard platform device was probed when `cros_ec_keyb_driver`
>   registered.  It deferred as its parent's drvdata was NULL[1].
> 
> - The transport platform device was probed when `cros_ec_lpc_driver`
>   registered.  It set the drvdata[3].
> 
> - The keyboard platform device was probed again from retrying the deferred
>   list, by another thread `deferred_probe_work_func`.  The parent's drvdata
>   wasn't NULL and cros_ec_register() for the transport device weren't
>   finished.  The race happened.

Hi Dmitry,

Does it make sense to you?