Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp710079ybz; Wed, 15 Apr 2020 17:14:13 -0700 (PDT) X-Google-Smtp-Source: APiQypLMJCOF3q0jShaZNGXlvbwq/VIRhHidbMwdH1FVP3TcimkXAE5CdQBNZGxGhtv1XzK7u2w2 X-Received: by 2002:a17:906:3709:: with SMTP id d9mr7664273ejc.94.1586996053605; Wed, 15 Apr 2020 17:14:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586996053; cv=none; d=google.com; s=arc-20160816; b=Q0AirhxldogA34ojVUBNc6XmOkagmYf2UsHdinIUJPfWr1LrryhXzd4BkaZ9lLEipV YEdfOi9nBpt5riVoSKv3Xcs+PoSOebeCl4LrGmBuCnf9ua0iqh2fZV2bfMMT+yRhnAbS 1nmdq8KazRjuiWroqrWMcbmvY6QitOniWICgCbwynR7gArF9B4bX45zoHoh3IjOmja83 JseqAtYaNJghrH4T4h1aaFndY2OsSilcHBkh1o2iS35RuSZur7hn1ONjkCDoFnXRsSN6 QSoIZl6hJOy1WSTP3CEj6JdCdgamErIYshTfEG29hU9ViZ9RMLxPTRrI7k+fHImKJqsB 2Beg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=hmeXnuGIUK2TV/t4Hg1i/iaX+MNqth4m34L0zpiy1s8=; b=Job+FiK9KjtwZ40dTMTjDKUlE95txp916aubXDiyE5kpCWLepwKZ2wIEcvoUt/3O7b MXBlHhl/wV78BM/Rt0/0wTAlWmqP9W50xNtqCU/AJWHdTKx7DFaCTR4qZAEkb9jUdnbi 1FW/PkA0MdrI/ppmlYrVB5RACh055ocAuGmQLpSc40W4Uy7cSZNyKfE1DYg+kLsqj2u8 I8EkCRVCs8+8f94N5ql+8bGhv5GGltZu3rVFn9A0KdcTq9XUIx/hRLgxozRqyJXmbmZK oOrjIFgfyUcYu31/JUYqHjyneCnSvZgIFifBwDgfKJswR5xTnB71DnI/aB4NoEu5Zzcr JtQA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s23si11033305edy.522.2020.04.15.17.13.50; Wed, 15 Apr 2020 17:14:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408893AbgDOOxu (ORCPT + 99 others); Wed, 15 Apr 2020 10:53:50 -0400 Received: from mx2.suse.de ([195.135.220.15]:54986 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407940AbgDOOxs (ORCPT ); Wed, 15 Apr 2020 10:53:48 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 53B93AB3D; Wed, 15 Apr 2020 14:53:45 +0000 (UTC) Date: Wed, 15 Apr 2020 14:53:45 +0000 (UTC) From: Michael Matz To: Borislav Petkov cc: Jakub Jelinek , Sergei Trofimovich , linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , x86@kernel.org Subject: Re: [PATCH v2] x86: fix early boot crash on gcc-10 In-Reply-To: <20200415074842.GA31016@zn.tnic> Message-ID: References: <20200326223501.GK11398@zn.tnic> <20200328084858.421444-1-slyfox@gentoo.org> <20200413163540.GD3772@zn.tnic> <20200415074842.GA31016@zn.tnic> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, 15 Apr 2020, Borislav Petkov wrote: > On Tue, Apr 14, 2020 at 01:50:29PM +0000, Michael Matz wrote: > > So this part expects that the caller (!) of trace_hardirqs_on was compiled > > with a frame pointer (in %ebp). > > /me looks at the .s file... > > options passed comment at the top has -fno-omit-frame-pointer > > > Obviously that's not the case as you traced above. Is start_secondary > > the immediate caller in the above case? > > Yes, start_secondary() is the function which is marked as > __attribute__((optimize("-fno-stack-protector"))) and it does: > > # arch/x86/kernel/smpboot.c:264: local_irq_enable(); > call trace_hardirqs_on # > > (the local_irq_enable() is a macro which has the call to > trace_hardirqs_on(). > > > Look at it's disassembly. If it doesn't have the usual push > > %ebp/mov%esp,%ebp prologue it probably doesn't use a frame pointer. > > Here's the preamble: > > .text > .p2align 4 > .type start_secondary, @function > start_secondary: > pushl %esi # > pushl %ebx # Right. So meanwhile it became clear: the optimize function attribute doesn't work cumulative but rather replaces all cmdline args (the optimization ones, but that roughly translates to -fxxx options). In this case an 'optimize("-fno-stack-protector")' also disables the crucial -fno-omit-frame-pointer, reverting to the compilers default, which, depending on version, is also to omit the frame pointer on 32bit. You could fix that by adding ',-fno-omit-frame-pointer' to the attribute string. But that quickly gets out of hand, considering all the options you carefully need to set in Makefiles to get the right behaviour. (Note that e.g. the optimization level is reset to -O0 as well!). (I'll admit that I was somewhat surprised by this behaviour, even though it makes sense in the abstract; resetting to a clean slate and everything). I think in its current form the optimize attribute is not useful for the purposes you need, and you're better off to disable the stack protector for the whole compilation unit from the Makefile. (That attribute is also documented as "not suitable in production code", so go figure ;-) ) I think it will be possible to make that attribute a bit more useful in the future, but for the time being I think you'll just want to live without it. Ciao, Michael.