• R
    driver core / ACPI: Avoid device hot remove locking issues · 5e33bc41
    Rafael J. Wysocki 提交于
    device_hotplug_lock is held around the acpi_bus_trim() call in
    acpi_scan_hot_remove() which generally removes devices (it removes
    ACPI device objects at least, but it may also remove "physical"
    device objects through .detach() callbacks of ACPI scan handlers).
    Thus, potentially, device sysfs attributes are removed under that
    lock and to remove those attributes it is necessary to hold the
    s_active references of their directory entries for writing.
    
    On the other hand, the execution of a .show() or .store() callback
    from a sysfs attribute is carried out with that attribute's s_active
    reference held for reading.  Consequently, if any device sysfs
    attribute that may be removed from within acpi_scan_hot_remove()
    through acpi_bus_trim() has a .store() or .show() callback which
    acquires device_hotplug_lock, the execution of that callback may
    deadlock with the removal of the attribute.  [Unfortunately, the
    "online" device attribute of CPUs and memory blocks is one of them.]
    
    To avoid such deadlocks, make all of the sysfs attribute callbacks
    that need to lock device hotplug, for example store_online(), use
    a special function, lock_device_hotplug_sysfs(), to lock device
    hotplug and return the result of that function immediately if it is
    not zero.  This will cause the s_active reference of the directory
    entry in question to be released and the syscall to be restarted
    if device_hotplug_lock cannot be acquired.
    
    [show_online() actually doesn't need to lock device hotplug, but
    it is useful to serialize it with respect to device_offline() and
    device_online() for the same device (in case user space attempts to
    run them concurrently) which can be done with the help of
    device_lock().]
    Reported-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Reported-and-tested-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
    Suggested-by: NTejun Heo <tj@kernel.org>
    Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    Acked-by: NToshi Kani <toshi.kani@hp.com>
    5e33bc41
memory.c 18.5 KB