On Thu, 2007-09-27 at 14:33 +0800, Alexey Starikovskiy wrote: > Shaohua Li wrote: > > 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. > What is because you didn't call .add() yet, or already > called .remove(), yes? > > Hi, Alexey, sorry that I'm not quite clear about what you mean above. IMO, many methods are evaluated to set all kinds of flags during the acpi_scan_init(), which may be invalid if the device isn't physically present. > > The real problem here is ACPICA will call some drivers routines > > (notification handler), but doesn't get a reference count of the > driver > > module. > We just should be able to load drivers for declared, but physically > absent devices. > > For the hot-plug case, we can move all the code to the per-device notify handler, which is called in the last minute. Then in the generic notify handler, we need to send a uevent to load the driver dynamically when a new device is inserted. Or we can add the hot_add code in generic notify handler and move the hot_removal code to the per-device notify handler, this is much easier while it's a kind of ugly. Thanks, Rui - 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
