PCI: sysfs: Ignore lockdep for remove attribute
With CONFIG_PROVE_LOCKING=y, using sysfs to remove a bridge with a device below it causes a lockdep warning, e.g., # echo 1 > /sys/class/pci_bus/0000:00/device/0000:00:00.0/remove ============================================ WARNING: possible recursive locking detected ... pci_bus 0000:01: busn_res: [bus 01] is released The remove recursively removes the subtree below the bridge. Each call uses a different lock so there's no deadlock, but the locks were all created with the same lockdep key so the lockdep checker can't tell them apart. Mark the "remove" sysfs attribute with __ATTR_IGNORE_LOCKDEP() as it is safe to ignore the lockdep check between different "remove" kernfs instances. There's discussion about a similar issue in USB at [1], which resulted in356c05d58a
("sysfs: get rid of some lockdep false positives") ande9b526fe70
("i2c: suppress lockdep warning on delete_device"), which do basically the same thing for USB "remove" and i2c "delete_device" files. [1] https://lore.kernel.org/r/Pine.LNX.4.44L0.1204251436140.1206-100000@iolanthe.rowland.org Link: https://lore.kernel.org/r/20190526225151.3865-1-marek.vasut@gmail.com Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> [bhelgaas: trim commit log, details at above links] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Tejun Heo <tj@kernel.org> Cc: Wolfram Sang <wsa@the-dreams.de>
This commit is contained in:
parent
de76cda215
commit
dc6b698a86
|
@ -480,7 +480,7 @@ static ssize_t remove_store(struct device *dev, struct device_attribute *attr,
|
|||
pci_stop_and_remove_bus_device_locked(to_pci_dev(dev));
|
||||
return count;
|
||||
}
|
||||
static struct device_attribute dev_remove_attr = __ATTR(remove,
|
||||
static struct device_attribute dev_remove_attr = __ATTR_IGNORE_LOCKDEP(remove,
|
||||
(S_IWUSR|S_IWGRP),
|
||||
NULL, remove_store);
|
||||
|
||||
|
|
Loading…
Reference in New Issue