On Fri, Jan 25, 2013 at 11:57 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Fri, Jan 25, 2013 at 9:44 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> [+cc Yinghai] >> >> On Fri, Jan 25, 2013 at 3:02 AM, Gu Zheng > > Hi, Gu, > > Can you check if two patches in > > http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=shortlog;h=refs/heads/for-pci-root-bus-hotplug-part3 > > could solve your problem? > > http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=277df390baeab7ba6aa136356b677a096c890c0c > > PCI: Rescan bus using callback method too > > > http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=282e2db3b58d56b5236ee755e1527574df0d298e > > PCI, sysfs: Clean up rescan/remove with scheule_callback You ignored and clipped my concerns about similar synchronization issues outside sysfs, so let me quote it again here: I'm sorry that you tripped over this deadlock, because now I'm worried about related locking issues outside sysfs :) The mutex you're fiddling with is only in sysfs, but the routines *protected* by that mutex are used in other places, too. So what happens when a hotplug driver does a rescan at the same time a user does a rescan or remove via sysfs? I don't even know what the rules are for protecting scan/remove, but I don't have confidence that the issue you're fixing is the only one. If we're going to fix the sysfs deadlock (and we should), I want to either see an argument for why we don't have a problem outside of sysfs, or I want to fix sysfs and non-sysfs at the same time. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
