summaryrefslogtreecommitdiffstats
path: root/include/asm-mips/sgidefs.h
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@novell.com>2006-03-23 02:59:45 -0800
committerLinus Torvalds <torvalds@g5.osdl.org>2006-03-23 07:38:05 -0800
commit101f12af16fb12f8da8100899a13ee1b1b576a0a (patch)
tree0bea73d2702ba438e8e82bc8000b498aa50aee6e /include/asm-mips/sgidefs.h
parent44fd22992cb76dc51c52cf4b8aff1bc7899bb23c (diff)
downloadop-kernel-dev-101f12af16fb12f8da8100899a13ee1b1b576a0a.zip
op-kernel-dev-101f12af16fb12f8da8100899a13ee1b1b576a0a.tar.gz
[PATCH] i386: actively synchronize vmalloc area when registering certain callbacks
Registering a callback handler through register_die_notifier() is obviously primarily intended for use by modules. However, the way these currently get called it is basically impossible for them to actually be used by modules, as there is, on non-PAE configurationes, a good chance (the larger the module, the better) for the system to crash as a result. This is because the callback gets invoked (a) in the page fault path before the top level page table propagation gets carried out (hence a fault to propagate the top level page table entry/entries mapping to module's code/data would nest infinitly) and (b) in the NMI path, where nested faults must absolutely not happen, since otherwise the IRET from the nested fault re-enables NMIs, potentially resulting in nested NMI occurences. Besides the modular aspect, similar problems would even arise for in- kernel consumers of the API if they touched ioremap()ed or vmalloc()ed memory inside their handlers. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'include/asm-mips/sgidefs.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud