diff options
author | Alex Chiang <achiang@hp.com> | 2008-07-01 20:02:23 -0600 |
---|---|---|
committer | Jesse Barnes <jbarnes@virtuousgeek.org> | 2008-07-02 11:27:30 -0700 |
commit | a13307cef8bf51990ef1d525b1cbdcc2cfe07e2a (patch) | |
tree | 3098b0057aa09f53c9ecd485fc147f135eecfc33 /net/sched/sch_atm.c | |
parent | 99cb233d60cbe644203f19938c729ea2bb004d70 (diff) | |
download | blackbird-op-linux-a13307cef8bf51990ef1d525b1cbdcc2cfe07e2a.tar.gz blackbird-op-linux-a13307cef8bf51990ef1d525b1cbdcc2cfe07e2a.zip |
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 'net/sched/sch_atm.c')
0 files changed, 0 insertions, 0 deletions