From: "Jan Beulich" <JBeulich@novell.com>
To: "Andrew Morton" <akpm@osdl.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] i386 double fault enhancements
Date: Thu, 23 Feb 2006 12:42:08 +0100 [thread overview]
Message-ID: <43FDADA0.76F0.0078.0@novell.com> (raw)
In-Reply-To: <20060222143212.0eea2ab0.akpm@osdl.org>
>>> Andrew Morton <akpm@osdl.org> 22.02.06 23:32:12 >>>
>Jan Beulich <jbeulich@novell.com> wrote:
>>
>> Make the double fault handler use CPU-specific stacks. Add some
>> abstraction to simplify future change of other exception handlers to go
>> through task gates. Change the pointer validity checks in the double
>> fault handler to account for the fact that both GDT and TSS aren't in
>> static kernel space anymore. Add a new notification of the event
>> through the die notifier chain, also providing some environmental
>> adjustments so that various infrastructural things work independent of
>> the fact that the fault and the callbacks are running on other then the
>> normal kernel stack.
>
>Why?
In addition to what Andi said, the infrastructural changes are so that you can do
more than just printk()ing information, namely enter a debugger. Even for printk()
I doubt someone has verified and can guarantee for the future that the possible
code paths never use any of the things that make assumptions about the current
stack (specifically, uses of thread_info).
>> +# ifdef CONFIG_SMP
>
>Please don't bother with the space after the #. Yes, it's for nesting
>level, but if someone later comes along and sticks more ifdefs around this
>code, they won't go through and add the extra spaces anyway.
Will change that.
>Such problems can be avoided by not adding the ifdefs at all..
Here, the code could probably be enabled always, but I dislike having dead code like
this needlessly compiled.
>> +#ifdef N_EXCEPTION_TSS
>
>Can't we use CONFIG_DOUBLEFAULT throughout? It's very much clearer.
We could, when not considering broader use. I specifically introduced N_EXCEPTION_TSS
so that it wouldn't be as hard as it currently is to have other exceptions got through task
gates (nlkd's fault/trap/abort infrastructure does, for example).
>> +struct tss_struct exception_tss[NR_CPUS][N_EXCEPTION_TSS] __cacheline_aligned = {
>> + [0 ... NR_CPUS-1] = {
>> + [0 ... N_EXCEPTION_TSS-1] = {
>> + .cs = __KERNEL_CS,
>> + .ss = __KERNEL_DS,
>> + .ss0 = __KERNEL_DS,
>> + .__cr3 = __pa(swapper_pg_dir),
>> + .io_bitmap_base = INVALID_IO_BITMAP_OFFSET,
>> + .ds = __USER_DS,
>> + .es = __USER_DS,
>> + .eflags = X86_EFLAGS_SF | 0x2, /* 0x2 bit is always set */
>> + },
>> + [DOUBLEFAULT_TSS].eip = (unsigned long)doublefault_fn
>> + }
>> +};
>> +#endif
>
>How much more RAM does this patch consume?
8k TSS plus 4k stack per CPU compared to a single global TSS plus 1k stack in current code. One could argue that the
I/O bitmap isn't really needed here, but mis-using it as stack wouldn't work well (because of the thread_info
restrictions the TSS would then need to be allocated so that the I/O bitmap gets page aligned), nor can it be easily
left off (struct tss_struct unfortunately includes this non-architectural part).
>> +#define EXCEPTION_STKSZ (PAGE_SIZE << EXCEPTION_STACK_ORDER)
>
>"EXCEPTION_STACK_SIZE", please.
Fine with me; just followed the x86-64 naming.
Jan
next prev parent reply other threads:[~2006-02-23 11:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-22 10:59 [PATCH] i386 double fault enhancements Jan Beulich
2006-02-22 22:32 ` Andrew Morton
2006-02-23 10:34 ` Andi Kleen
2006-02-23 11:42 ` Jan Beulich [this message]
2006-02-24 18:49 ` Christoph Hellwig
2006-03-03 9:30 ` Jan Beulich
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=43FDADA0.76F0.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=akpm@osdl.org \
--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