On Monday, June 17, 2013 01:12:00 AM Jiang Liu wrote: > On 06/16/2013 06:54 AM, Rafael J. Wysocki wrote: > > On Saturday, June 15, 2013 11:20:40 PM Rafael J. Wysocki wrote: > >> On Saturday, June 15, 2013 10:17:42 PM Rafael J. Wysocki wrote: > > > > [...] > > > >> > >> Which sysfs interfaces do you mean, by the way? > >> > >> If you mean "eject", then it takes acpi_scan_lock and hotplug_dock_devices() > >> should always be run under acpi_scan_lock too. It isn't at the moment, > >> because write_undock() doesn't take acpi_scan_lock(), but this is an obvious > >> bug (so I'm going to send a patch to fix it in a while). > >> > >> With that bug fixed, the possible race between acpi_eject_store() and > >> hotplug_dock_devices() should be prevented from happening, so perhaps we're > >> worrying about something that cannot happen? > > > > So here's a question: What particular races are possible if we remove > > ds->hp_lock entirely without doing anything else just yet? I mean, how to > > *trigger* them from the start to the end and not how they can possibly happen > > but never do, because there's no way they can be actually triggered? > Hi Rafael, > I have no really platform which triggers this bug, but I may imagine > a possible platform if it's valid for explanation. > Let's think about a laptop dock station with a thunderbolt > controller built-in. The dock station is managed by dock driver and > acpiphp driver. And the PCIe hierarchy managed by the thunderbolt > controller may be managed by dock driver and ACPIPHP driver too. > So it may trigger the issue by pressing the dock button and unplugging > thunderbolt cable concurrently. > But after all, this is all by imagination:). We may need to find a > simple and quick solution for 3.10 and the stable trees and enhance the > solution later to avoid introducing new bugs while fixing a bug. Well, if that particular bug is not fixed in 3,10, it won't be a tragedy, and I *really* don't want that code to get substantially more complex than it is now. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
