From: Andi Kleen <ak@suse.de>
To: Jan Beulich <jbeulich@novell.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i386: actively synchronize vmalloc area when registering certain callbacks
Date: 22 Feb 2006 18:26:29 +0100 [thread overview]
Message-ID: <p73y8032tkq.fsf@verdi.suse.de> (raw)
In-Reply-To: <200602221203.23561.jbeulich@novell.com>
Jan Beulich <jbeulich@novell.com> writes:
> 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>
The patch is relatively complicated, but it's such a nasty corner case
(thanks Jan for discovering that one) that could easily hit in kernel
users like kprobes too so I think it's it's good fix it. I did the corresponding
change on x86-64 too.
Actually I tried to simplify it, but failed.
Acked-by: Andi Kleen <ak@suse.de>
prev parent reply other threads:[~2006-02-22 17:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-22 11:03 [PATCH] i386: actively synchronize vmalloc area when registering certain callbacks Jan Beulich
2006-02-22 17:26 ` Andi Kleen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=p73y8032tkq.fsf@verdi.suse.de \
--to=ak@suse.de \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox