On Tue, Mar 07, 2023 at 09:25:09AM -0500, Pierre Asselin wrote: > > 5.19: good. > 5.19+Uwe's patch: bad. > > Slightly different traceback, > https://www.panix.com/~pa/linux-6.1.12-crash/boot-failure-5.19-patched.jpg Maybe the following patch helps (on top of v6.3-rc1): diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 9531dd0fef50..a5a8f82981ce 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -518,7 +518,7 @@ static void acpi_bus_notify(acpi_handle handle, u32 type, void *data) if (!adev) goto err; - if (adev->dev.driver) { + if (device_is_bound(&adev->dev)) { struct acpi_driver *driver = to_acpi_driver(adev->dev.driver); if (driver && driver->ops.notify && This might be broken because usually you have to hold the device lock and this isn't given here I think. On the other hand, I don't know if you could just grab the lock here. You'd probably have to hold it while calling driver->ops.notify which might or might not be safe. I think there was a race already before commit d6fb6ee1820c ("ACPI: bus: Drop driver member of struct acpi_device"), it just wasn't hit that reliably. (Consider the state before d6fb6ee1820c and the device being unbound just between acpi_bus_notify()'s driver = adev->driver; and the call to driver->ops.notify. So conceptually it was necessary already before d6fb6ee1820c to hold the device lock?) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
