On Thu, 2007-09-27 at 10:24 +0400, Alexey Starikovskiy wrote: > Shaohua Li wrote: > > On Thu, 2007-09-27 at 11:30 +0800, Zhang Rui wrote: > >> Hi, all, > >> > >> I found a bug that linux/acpi may execute notify handler that > >> has been removed. > >> > >> When a system notify(0~0x7f) is received, linux/acpi will > >> first invoke the generic system notify handler (acpi_bus_notify) > >> and then invoke the per-device notify handler if present. > >> > >> In my case, I add some code in acpi_bus_notify for battery > >> hotplug support, so that the generic system notify handler will > >> remove the battery device, including the per-device notify handler > >> acpi_battery_notify() when receiving notification > >> ACPI_NOTIFY_EJECT_REQUEST. > >> But linux/acpi invokes the per-device notify handler soon and > >> this breaks the system. > >> > >> Further more, device hot-removal is not the only case to encounter > >> this bug. For example, linux/acpi receives a notification and adds it > >> in the workqueue, and then the driver(notify handler) is removed > >> before kacpid_notify invoke it... > > For the non-hotplug case, adding a flush work queue just after notify > > handler is removed should be ok. > I think, the real problem with ACPI hotplug is that we know which devices might appear -- > they are all enumerated in DSDT, but we don't add them until they appear. > If we do .add for all devices in DSDT, and then just .start/.stop them as they appear/disappear, > we will have to do much less work, and avoid a problem described above... If a device is not present, you can't access any method of it. The real problem here is ACPICA will call some drivers routines (notification handler), but doesn't get a reference count of the driver module. Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
