[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <507F473D.1060700@zytor.com>
Date: Wed, 17 Oct 2012 17:03:09 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC: linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
lenb@...nel.org, linux-acpi@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH 1/4] x86/wakeup/sleep: Check whether the TSS GDT descriptor
is empty before using it.
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> We check the TSS descriptor before we try to dereference it.
> Also fix up the value to use the #defines.
>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> ---
> arch/x86/power/cpu.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
> index 218cdb1..c17370e 100644
> --- a/arch/x86/power/cpu.c
> +++ b/arch/x86/power/cpu.c
> @@ -133,7 +133,9 @@ static void fix_processor_context(void)
> {
> int cpu = smp_processor_id();
> struct tss_struct *t = &per_cpu(init_tss, cpu);
> -
> +#ifdef CONFIG_X86_64
> + struct desc_struct *desc = get_cpu_gdt_table(cpu);
> +#endif
> set_tss_desc(cpu, t); /*
> * This just modifies memory; should not be
> * necessary. But... This is necessary, because
> @@ -142,7 +144,8 @@ static void fix_processor_context(void)
> */
>
> #ifdef CONFIG_X86_64
> - get_cpu_gdt_table(cpu)[GDT_ENTRY_TSS].type = 9;
> + if (!desc_empty(&desc[GDT_ENTRY_TSS]))
> + desc[GDT_ENTRY_TSS].type = DESC_TSS;
>
> syscall_init(); /* This sets MSR_*STAR and related */
> #endif
>
Why is this patch necessary? Presumably there is something further down
the line which depends on the TSS descriptor being empty, but if so, what?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists