From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750896AbeESHAN (ORCPT ); Sat, 19 May 2018 03:00:13 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:40615 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750743AbeESHAM (ORCPT ); Sat, 19 May 2018 03:00:12 -0400 Date: Sat, 19 May 2018 09:00:08 +0200 From: Pavel Machek To: Linus Torvalds , "Rafael J. Wysocki" Cc: 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: "interesting" entry in hibernation code was Re: [lkp-robot] [x86/asm] 51bad67ffb: int3:#[##] Message-ID: <20180519070008.GC30676@amd> References: <20180515080033.GA7714@yexl-desktop> <20180515210757.GA12225@avx2> <20180515214337.GA18021@avx2> <20180515222211.ods5hzne46hozojq@treble> <20180515224354.zmygmsnlqj5lrdbo@treble> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YD3LsXFS42OYHhNZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > Side note: doing some grepping, I find some other sequences that are a bit > scary, like this: >=20 > 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 >=20 > so apparently people are using ENTRY() for data too (the same pattern > exists in wakeup_64.S). >=20 > 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: =20 .data ALIGN -ENTRY(saved_magic) .long 0 -ENTRY(saved_eip) .long 0 +GLOBAL(saved_magic) .long 0 +saved_eip: .long 0 =20 # saved registers saved_idt: .long 0,0 Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlr/y3gACgkQMOfwapXb+vK5DQCgm0W/piplkNmZpougS2ZoBuo+ y4wAoL7WJcAuG3J28+jWH4zqDBbDaz+B =/D+M -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5809135286865142599==" MIME-Version: 1.0 From: Pavel Machek To: lkp@lists.01.org Subject: "interesting" entry in hibernation code was Re: [lkp-robot] [x86/asm] 51bad67ffb: int3:#[##] Date: Sat, 19 May 2018 09:00:08 +0200 Message-ID: <20180519070008.GC30676@amd> In-Reply-To: List-Id: --===============5809135286865142599== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 Pavel -- = (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --===============5809135286865142599== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlFWUVBUkVD QUFZRkFsci95M2dBQ2drUU1PZndhcFhiK3ZLNURRQ2dtMFcvcGlwbGtObVpwb3VnUzJab0J1bysK eTR3QW9MN1dKY0F1RzNKMjgraldINHpxREJiRGF6K0IKPS9EK00KLS0tLS1FTkQgUEdQIFNJR05B VFVSRS0tLS0tCg== --===============5809135286865142599==--