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

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

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.