From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
"H.J. Lu" <hjl.tools@gmail.com>, Borislav Petkov <bp@alien8.de>,
Jan Beulich <JBeulich@suse.com>,
Binutils <binutils@sourceware.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: Stop relying on magic jmp behavior for early_idt_handlers
Date: Thu, 21 May 2015 17:50:03 -0700 [thread overview]
Message-ID: <555E7D3B.3070804@zytor.com> (raw)
In-Reply-To: <CALCETrVTqTA+Xem3dUkWo46zmk5taG0U=2BmDJLj-S80QNjP7g@mail.gmail.com>
On 05/21/2015 05:38 PM, Andy Lutomirski wrote:
> On Thu, May 21, 2015 at 5:32 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 05/21/2015 05:17 PM, Andy Lutomirski wrote:
>>>
>>> diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h
>>> index 5a9856eb12ba..4bbe0eb24d7e 100644
>>> --- a/arch/x86/include/asm/segment.h
>>> +++ b/arch/x86/include/asm/segment.h
>>> @@ -231,12 +231,21 @@
>>> #define TLS_SIZE (GDT_ENTRY_TLS_ENTRIES* 8)
>>>
>>> #ifdef __KERNEL__
>>> -#ifndef __ASSEMBLY__
>>>
>>> -extern const char early_idt_handlers[NUM_EXCEPTION_VECTORS][2+2+5];
>>> +/*
>>> + * early_idt_handlers is an array of entry points. For simplicity, it's
>>> + * a real array. We allocate nine bytes for each entry: two one-byte
>>> + * push instructions and a five-byte jump in the worst case.
>>> + */
>>> +#define EARLY_IDT_HANDLER_STRIDE 9
>>> +#ifndef __ASSEMBLY__
>>> +extern const char early_idt_handlers[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_STRIDE];
>>> #ifdef CONFIG_TRACING
>>> # define trace_early_idt_handlers early_idt_handlers
>>> #endif
>>> +#endif
>>> +
>>> +#ifndef __ASSEMBLY__
>>>
>>
>> Please get rid of the unnecessary #ifndef/#endif pair.
>
> I did it to preserve logical nesting. I didn't want the pile of
> early_idt_handlers declarations and comments to have the side affect
> of starting an #ifdef block.
>
> If you still think I should change it, I'll change it.
>
Please change it. We generally don't do that kind of logical nesting,
it is just clutter.
-hpa
prev parent reply other threads:[~2015-05-22 0:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-22 0:17 [PATCH] x86: Stop relying on magic jmp behavior for early_idt_handlers Andy Lutomirski
2015-05-22 0:32 ` H. Peter Anvin
2015-05-22 0:38 ` Andy Lutomirski
2015-05-22 0:50 ` H. Peter Anvin [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=555E7D3B.3070804@zytor.com \
--to=hpa@zytor.com \
--cc=JBeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=bp@alien8.de \
--cc=hjl.tools@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.