From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752173AbeESIgJ (ORCPT ); Sat, 19 May 2018 04:36:09 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:54706 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751975AbeESIgF (ORCPT ); Sat, 19 May 2018 04:36:05 -0400 From: "Rafael J. Wysocki" To: Pavel Machek Cc: Linus Torvalds , Josh Poimboeuf , Alexey Dobriyan , Peter Anvin , kernel test robot , Ingo Molnar , Thomas Gleixner , Andrew Lutomirski , Borislav Petkov , Brian Gerst , Denys Vlasenko , Peter Zijlstra , Linux Kernel Mailing List , Peter Anvin , tipbuild@zytor.com, LKP Subject: Re: "interesting" entry in hibernation code was Re: [lkp-robot] [x86/asm] 51bad67ffb: int3:#[##] Date: Sat, 19 May 2018 10:35:27 +0200 Message-ID: <6938886.d705BbSbgG@aspire.rjw.lan> In-Reply-To: <20180519070008.GC30676@amd> References: <20180515080033.GA7714@yexl-desktop> <20180519070008.GC30676@amd> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1765896001640090334==" MIME-Version: 1.0 From: Rafael J. Wysocki To: lkp@lists.01.org Subject: Re: "interesting" entry in hibernation code was Re: [lkp-robot] [x86/asm] 51bad67ffb: int3:#[##] Date: Sat, 19 May 2018 10:35:27 +0200 Message-ID: <6938886.d705BbSbgG@aspire.rjw.lan> In-Reply-To: <20180519070008.GC30676@amd> List-Id: --===============1765896001640090334== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/wake= up_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 --===============1765896001640090334==--