From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752318AbeEOXFq (ORCPT ); Tue, 15 May 2018 19:05:46 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:51550 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751859AbeEOXFp (ORCPT ); Tue, 15 May 2018 19:05:45 -0400 X-Google-Smtp-Source: AB8JxZrStJURmq2H9i5YxmWvx9gCuLYpQ9YY3989XSjbLHzY1s0mEA9J6JnQgoqE8o7vJyeIv3/odXldriJ3jnEGKQ0= MIME-Version: 1.0 References: <20180515080033.GA7714@yexl-desktop> <20180515210757.GA12225@avx2> <20180515214337.GA18021@avx2> <20180515222211.ods5hzne46hozojq@treble> <20180515224354.zmygmsnlqj5lrdbo@treble> In-Reply-To: From: Linus Torvalds Date: Tue, 15 May 2018 16:05:33 -0700 Message-ID: Subject: Re: [lkp-robot] [x86/asm] 51bad67ffb: int3:#[##] To: Josh Poimboeuf Cc: 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Not an actual problem, but it does show that people seem to be mis-using ENTRY(). There that padding is actually entirely wrong. We do *not* want to pad between those "saved_xyz" fields. I think those should use GLOBAL too. Or lookie here: arch/x86/kernel/head_32.S-# boot GDT descriptor (later on used by CPU#0): arch/x86/kernel/head_32.S- .word 0 # 32 bit align gdt_desc.address arch/x86/kernel/head_32.S:ENTRY(early_gdt_descr) arch/x86/kernel/head_32.S- .word GDT_ENTRIES*8-1 arch/x86/kernel/head_32.S- .long gdt_page /* Overwritten for secondary CPUs */ where ENTRY() will actually screw up how the code says it wants to align the address, but now it doesn't. I wonder if there's some way to add a test for "ENTRY only works in a code section"? My grep was just me doing a visual scan, I might have missed something. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============8790799374579907799==" MIME-Version: 1.0 From: Linus Torvalds To: lkp@lists.01.org Subject: Re: [lkp-robot] [x86/asm] 51bad67ffb: int3:#[##] Date: Tue, 15 May 2018 16:05:33 -0700 Message-ID: In-Reply-To: List-Id: --===============8790799374579907799== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. Not an actual problem, but it does show that people seem to be mis-using ENTRY(). There that padding is actually entirely wrong. We do *not* want to pad between those "saved_xyz" fields. I think those should use GLOBAL too. Or lookie here: arch/x86/kernel/head_32.S-# boot GDT descriptor (later on used by CPU#0): arch/x86/kernel/head_32.S- .word 0 # 32 bit align gdt_desc.address arch/x86/kernel/head_32.S:ENTRY(early_gdt_descr) arch/x86/kernel/head_32.S- .word GDT_ENTRIES*8-1 arch/x86/kernel/head_32.S- .long gdt_page /* Overwritten for secondary CPUs */ where ENTRY() will actually screw up how the code says it wants to align the address, but now it doesn't. I wonder if there's some way to add a test for "ENTRY only works in a code section"? My grep was just me doing a visual scan, I might have missed something. Linus --===============8790799374579907799==--