summaryrefslogtreecommitdiff
path: root/fs/9p/v9fs_vfs.h
diff options
context:
space:
mode:
authorAlex Chiang <achiang@hp.com>2008-07-02 06:02:23 +0400
committerJesse Barnes <jbarnes@virtuousgeek.org>2008-07-02 22:27:30 +0400
commita13307cef8bf51990ef1d525b1cbdcc2cfe07e2a (patch)
tree3098b0057aa09f53c9ecd485fc147f135eecfc33 /fs/9p/v9fs_vfs.h
parent99cb233d60cbe644203f19938c729ea2bb004d70 (diff)
downloadlinux-a13307cef8bf51990ef1d525b1cbdcc2cfe07e2a.tar.xz
PCI: acpiphp: cleanup notify handler on all root bridges
During the development of the physical PCI slot patch series, Gary Hade kept on reporting strange oopses due to interactions between pci_slot and acpiphp. http://lkml.org/lkml/2007/11/28/319 find_root_bridges() unconditionally installs handle_hotplug_event_bridge() as an ACPI_SYSTEM_NOTIFY handler for all root bridges. However, during module cleanup, remove_bridge() will only remove the notify handler iff the root bridge had a hot-pluggable slot directly underneath. That is: root bridge -> hotplug slot But, if the topology looks like either of the following: root bridge -> non-hotplug slot root bridge -> p2p bridge -> hotplug slot Then we currently do not remove the notify handler from that root bridge. This can cause a kernel oops if we modprobe acpiphp later and it gets loaded somewhere else in memory. If the root bridge then receives a hotplug event, it will then attempt to call a stale, non-existent notify handler and we blow up. Much thanks goes to Gary Hade for his persistent debugging efforts. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Gary Hade <garyhade@us.ibm.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Diffstat (limited to 'fs/9p/v9fs_vfs.h')
0 files changed, 0 insertions, 0 deletions