[PATCH v2] gpiolib: Fix triggering "kobject: 'gpiochipX' is not initialized, yet" kobject_get() errors

[PATCH v2] gpiolib: Fix triggering "kobject: 'gpiochipX' is not initialized, yet" kobject_get() errors

[Hans de Goede]

When a gpiochip gets added by loading a module, then another driver may
be waiting for that gpiochip to load on the deferred-probe list.

If the deferred-probe for the consumer of gpiochip then triggers between
the gpiodev_add_to_list_unlocked() calls which makes gpio_device_find()
see the chip and the gpiochip_setup_dev() later then gpio_device_find()
does a kobject_get() on an uninitialzed kobject since the kobject is
initialized by gpiochip_setup_dev() calling device_initialize():

 arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring
 arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring
 ------------[ cut here ]------------
 kobject: 'gpiochip5' (00000000241466f2): is not initialized, yet kobject_get() is being called.
 WARNING: CPU: 3 PID: 42 at lib/kobject.c:640 kobject_get+0x43/0x70
 Call Trace:
  kobject_get
  gpio_device_find
  gpiod_find_and_request
  gpiod_get
  snd_byt_wm5102_mc_probe

Not only is the device not initialized yet, but when the gpio-device is
added to the list things like the irqchip also have not been initialized
yet.

So gpio_device_find() should really ignore the gpio-device until
gpiochip_add_data_with_key() is fully done. Add a device_is_registered()
check to gpio_device_find() to ignore gpio-devices on the list which are
not yet fully initialized.

Fixes: aab5c6f20023 ("gpio: set device type for GPIO chips")
Suggested-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Move device_is_registered() outside of RCU read lock section
-Simplify backtrace in commit msg
-Add fixes tag
---
 drivers/gpio/gpiolib.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 59ccf9a3e153..94903fc1c145 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1175,6 +1175,9 @@ struct gpio_device *gpio_device_find(const void *data,
 
 	list_for_each_entry_srcu(gdev, &gpio_devices, list,
 				 srcu_read_lock_held(&gpio_devices_srcu)) {
+		if (!device_is_registered(&gdev->dev))
+			continue;
+
 		guard(srcu)(&gdev->srcu);
 
 		gc = srcu_dereference(gdev->chip, &gdev->srcu);
-- 
2.44.0

Re: [PATCH v2] gpiolib: Fix triggering "kobject: 'gpiochipX' is not initialized, yet" kobject_get() errors

[Andy Shevchenko]

On Tue, Apr 2, 2024 at 7:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> When a gpiochip gets added by loading a module, then another driver may
> be waiting for that gpiochip to load on the deferred-probe list.
>
> If the deferred-probe for the consumer of gpiochip then triggers between
> the gpiodev_add_to_list_unlocked() calls which makes gpio_device_find()
> see the chip and the gpiochip_setup_dev() later then gpio_device_find()
> does a kobject_get() on an uninitialzed kobject since the kobject is

uninitialized

> initialized by gpiochip_setup_dev() calling device_initialize():
>
>  arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring
>  arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring
>  ------------[ cut here ]------------
>  kobject: 'gpiochip5' (00000000241466f2): is not initialized, yet kobject_get() is being called.
>  WARNING: CPU: 3 PID: 42 at lib/kobject.c:640 kobject_get+0x43/0x70
>  Call Trace:
>   kobject_get
>   gpio_device_find
>   gpiod_find_and_request
>   gpiod_get
>   snd_byt_wm5102_mc_probe
>
> Not only is the device not initialized yet, but when the gpio-device is
> added to the list things like the irqchip also have not been initialized
> yet.
>
> So gpio_device_find() should really ignore the gpio-device until
> gpiochip_add_data_with_key() is fully done. Add a device_is_registered()
> check to gpio_device_find() to ignore gpio-devices on the list which are
> not yet fully initialized.

Reviewed-by: Andy Shevchenko <andy@kernel.org>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] gpiolib: Fix triggering "kobject: 'gpiochipX' is not initialized, yet" kobject_get() errors

[Hans de Goede]

Hi,

On 4/2/24 6:51 PM, Andy Shevchenko wrote:
> On Tue, Apr 2, 2024 at 7:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> When a gpiochip gets added by loading a module, then another driver may
>> be waiting for that gpiochip to load on the deferred-probe list.
>>
>> If the deferred-probe for the consumer of gpiochip then triggers between
>> the gpiodev_add_to_list_unlocked() calls which makes gpio_device_find()
>> see the chip and the gpiochip_setup_dev() later then gpio_device_find()
>> does a kobject_get() on an uninitialzed kobject since the kobject is
> 
> uninitialized

Bartosz, can you fix this up while merging or do you prefer a v3?


>> initialized by gpiochip_setup_dev() calling device_initialize():
>>
>>  arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring
>>  arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring
>>  ------------[ cut here ]------------
>>  kobject: 'gpiochip5' (00000000241466f2): is not initialized, yet kobject_get() is being called.
>>  WARNING: CPU: 3 PID: 42 at lib/kobject.c:640 kobject_get+0x43/0x70
>>  Call Trace:
>>   kobject_get
>>   gpio_device_find
>>   gpiod_find_and_request
>>   gpiod_get
>>   snd_byt_wm5102_mc_probe
>>
>> Not only is the device not initialized yet, but when the gpio-device is
>> added to the list things like the irqchip also have not been initialized
>> yet.
>>
>> So gpio_device_find() should really ignore the gpio-device until
>> gpiochip_add_data_with_key() is fully done. Add a device_is_registered()
>> check to gpio_device_find() to ignore gpio-devices on the list which are
>> not yet fully initialized.
> 
> Reviewed-by: Andy Shevchenko <andy@kernel.org>

Thank you for the review.

Regards,

Hans

Re: [PATCH v2] gpiolib: Fix triggering "kobject: 'gpiochipX' is not initialized, yet" kobject_get() errors

[Bartosz Golaszewski]

On Wed, Apr 3, 2024 at 10:17 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 4/2/24 6:51 PM, Andy Shevchenko wrote:
> > On Tue, Apr 2, 2024 at 7:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >> When a gpiochip gets added by loading a module, then another driver may
> >> be waiting for that gpiochip to load on the deferred-probe list.
> >>
> >> If the deferred-probe for the consumer of gpiochip then triggers between
> >> the gpiodev_add_to_list_unlocked() calls which makes gpio_device_find()
> >> see the chip and the gpiochip_setup_dev() later then gpio_device_find()
> >> does a kobject_get() on an uninitialzed kobject since the kobject is
> >
> > uninitialized
>
> Bartosz, can you fix this up while merging or do you prefer a v3?
>

Yes, queued for fixes.

Bart