Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp4474732img; Tue, 26 Mar 2019 10:05:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqwmebAEcWAEYEIIyfqF235AsXpmMEk0xDOlc+VhILIfLrsQS7CZYGH3H6BHQMg4Lig7tXFl X-Received: by 2002:a17:902:8bc3:: with SMTP id r3mr8621787plo.53.1553619904579; Tue, 26 Mar 2019 10:05:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553619904; cv=none; d=google.com; s=arc-20160816; b=tyB91rsUfV6pZgWlEM4KsNmTRkn6/Q987kDmd5/dVditdItyxGxrKvYcD2J9ajQRf3 lvmHaxIisMRss/IwSxeSoq8kgpRlyi43Cx3S1VribEXaGULQ0j8OEBjLMP6xXQVsfxRq N7qJye8ilCYC+gXJYUUis327ZuZn8waHssB4469KeVZJATs3Zk436z9GIznAjpPOyT9n zK/LvNoFzejGff6kg2oDHTnkUlS87LcRB0MgO53mMR8NL3hfSCZAlvDk8ui5qCQQWxES /RqKPH73irNl1uxMJ3dbiIhmHgzBLohidWpUYZ6G3Q6xrk4vyReIrqbMGDZ1UAJAC7xE 2V2A== 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=v2SO9B8atQxYzNuwk4B1uTDXgwU01UJFOJBcGOdc65Y=; b=CzUFWOIzdMcMICI48Toeg+Etzsf0wCCqyS3M3ioTLRauOKCOxnYo0vnq/QNPBLypUK ab5x0gMMFTv1L2S1Ug5zqLiK+pB35p8mEN8xLRRehd6ORxkfhbbaTejHXlxkKGyQJtFC 802SffHPVPetAd7cww9l3Op9wby8G86kk6sltpIQJIYv1RnuVdfsuznOhaHW7srkjQDM RkFFaHKW88hhlVcuPSXdHhTuQVo6MwjrCgD4iQuvIZvyNX2BEwHtbvMxxjXb+g9yyYLD 2hr+GbIMElcDjW2nxtZuorYNnYXIfLh2SwD/2/fun3eYn7KNeqnw5fxLt4anMa4DZ9vh QHgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j37si14009817plb.236.2019.03.26.10.04.49; Tue, 26 Mar 2019 10:05:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731816AbfCZRED (ORCPT + 99 others); Tue, 26 Mar 2019 13:04:03 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:48920 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726278AbfCZRED (ORCPT ); Tue, 26 Mar 2019 13:04:03 -0400 Received: from p5492e2fc.dip0.t-ipconnect.de ([84.146.226.252] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1h8pUV-000267-Ef; Tue, 26 Mar 2019 18:03:59 +0100 Date: Tue, 26 Mar 2019 18:03:59 +0100 (CET) From: Thomas Gleixner To: Andi Kleen cc: x86@kernel.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Andi Kleen Subject: Re: [PATCH 02/17] x86, lto: Mark all top level asm statements as .text In-Reply-To: <20190321220009.29334-3-andi@firstfloor.org> Message-ID: References: <20190321220009.29334-1-andi@firstfloor.org> <20190321220009.29334-3-andi@firstfloor.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-436328035-1553619839=:1789" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-436328035-1553619839=:1789 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Andi, On Thu, 21 Mar 2019, Andi Kleen wrote: > With gcc 8 toplevel assembler statements that do not mark themselves > as .text may end up in other sections. Which is clearly a change in behaviour. Is that intended or just yet another feature of GCC? Your subject says: 'x86, lto:' So is this a LTO related problem or is the section randomization independent of LTO? This wants to be clearly documented in the changelog. Aside of that the proper Subject prefix is either: x86/asm/lto: or x86/asm: dependent on the nature. Like it or not, but this has been the prefix x86 uses for a very long time already. > I had boot crashes because > various assembler statements ended up in the middle of the initcall > section. > > Always mark all the top level assembler statements as text > so that they switch to the right section. > > For AMD "vide", which is only used on 32bit kernels, I also > marked it as 32bit only. Once more. See https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes "Describe your changes in imperative mood, e.g. “make xyzzy do frotz” instead of “[This patch] makes xyzzy do frotz” or “[I] changed xyzzy to do frotz”, as if you are giving orders to the codebase to change its behaviour." This is the last time, I'm asking for this. Thanks, tglx --8323329-436328035-1553619839=:1789--