diff options
author | Jan Beulich <jbeulich@novell.com> | 2006-03-23 02:59:45 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-03-23 07:38:05 -0800 |
commit | 101f12af16fb12f8da8100899a13ee1b1b576a0a (patch) | |
tree | 0bea73d2702ba438e8e82bc8000b498aa50aee6e /include/asm-mips/sgidefs.h | |
parent | 44fd22992cb76dc51c52cf4b8aff1bc7899bb23c (diff) | |
download | op-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