lkml.org 
[lkml]   [2018]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: "interesting" entry in hibernation code was Re: [lkp-robot] [x86/asm] 51bad67ffb: int3:#[##]
Date
On Saturday, May 19, 2018 9:00:08 AM CEST Pavel Machek wrote:
> Hi!
>
> > Side note: doing some grepping, I find some other sequences that are a bit
> > scary, like this:
> >
> > arch/x86/kernel/acpi/wakeup_32.S-.data
> > arch/x86/kernel/acpi/wakeup_32.S-ALIGN
> > arch/x86/kernel/acpi/wakeup_32.S:ENTRY(saved_magic) .long 0
> > arch/x86/kernel/acpi/wakeup_32.S:ENTRY(saved_eip) .long 0
> >
> > so apparently people are using ENTRY() for data too (the same pattern
> > exists in wakeup_64.S).
> >
> > So we end up having those odd 0x90 bytes (now 0xcc) in the data section as
> > "padding" between those two values. Crazy.
>
> Sorry about that. I'm pretty sure intention was simply to use the
> variable from C code.. and ENTRY() worked. I was not aware that it has
> side effect of padding...
>
> Let me see how this can be improved... (untested).
>
> diff --git a/arch/x86/kernel/acpi/wakeup_32.S b/arch/x86/kernel/acpi/wakeup_32.S
> index 0c26b1b..d6f477f 100644
> --- a/arch/x86/kernel/acpi/wakeup_32.S
> +++ b/arch/x86/kernel/acpi/wakeup_32.S
> @@ -89,8 +89,8 @@ ret_point:
>
> .data
> ALIGN
> -ENTRY(saved_magic) .long 0
> -ENTRY(saved_eip) .long 0
> +GLOBAL(saved_magic) .long 0
> +saved_eip: .long 0
>
> # saved registers
> saved_idt: .long 0,0

The Jiri Slaby's annotation patches touch this:

https://patchwork.kernel.org/patch/10409073/

Thanks,
Rafael

\
 
 \ /
  Last update: 2018-05-19 10:36    [W:0.141 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site