Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3848202imw; Mon, 18 Jul 2022 15:56:29 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vmbgAzNJyMh7x9VW5A3xOHFgpONPQR45W/wkhgOU+4x7zisUCvqI+s6CTQDNQywRXI/HJp X-Received: by 2002:a17:90b:4c8c:b0:1ef:bff6:c964 with SMTP id my12-20020a17090b4c8c00b001efbff6c964mr33814336pjb.36.1658184989535; Mon, 18 Jul 2022 15:56:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658184989; cv=none; d=google.com; s=arc-20160816; b=sOdPx1ODnm8om99H73edfPrCaLLTqJ7e8n8Hqp2i5g/kJh/eZ79QzyreWIroI0Fcr0 DkTDm6hIEY8LX9La6VK0ZXJM0OXM4h0RX69UzPIlWVOBbmKlqQ41HG2aPW+tOG+gw5IW 4X4TysraDXkf4vWPKLqpsY9730C2kYBXTqGTETCMncUcKslgraVn9AlYm4QmZc2lYlt4 qVwVR9hDJ/MFFI1U0r6TA5URgEaEFA6NtaAbVktFlfhd1SVhq03PTFhwZei3Tnt2MkDd BXxmHuUyAVqSmYhm0bHhtBX21+JPO1vdz9RG7nYrErnUI+VEs4YlYGveuiZ7gjuZ9oxD tNxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=hMlz+vn5loEPQvtk2SaQWF8f5Es9FhTyrx5oXqrFQto=; b=uLZ+bUScudA8+z36m3nlmB03Fsa/W11//UJRZRlvAIIo1QkU3HI/yWQBvkqWxWtcGP KqVQarppcHEQzdHw2moK2Tw7ZnsvRJOLXFMSGs7NRiXDbGUJAiR9Xa+T65CaohsRbV8q oFFnXX7nthqvx6vHBY+GJLPhQ1bbt+aS0wpb8P3gJBTy9cnfNrOG4LXQAKKOb9yOmi4P MRNhUYtLvCVzd9XuA43dlQoFVdP+bxKqKHQ6wMtIpkFseqtd4IrvEu6wbD1hSnz9lV9/ p8Pf1jtQN4K381rVp7rvBGobvb5rSQmFe9s/g5eJ8Nlrhpj1Va/WMGmSJmMhORyDVn9k 1w3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=LXdx5yqq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w185-20020a6382c2000000b004124f034b49si16574222pgd.529.2022.07.18.15.56.14; Mon, 18 Jul 2022 15:56:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=LXdx5yqq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231687AbiGRWfN (ORCPT + 99 others); Mon, 18 Jul 2022 18:35:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230263AbiGRWfM (ORCPT ); Mon, 18 Jul 2022 18:35:12 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59E2F167C2 for ; Mon, 18 Jul 2022 15:35:11 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id fy29so22805730ejc.12 for ; Mon, 18 Jul 2022 15:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hMlz+vn5loEPQvtk2SaQWF8f5Es9FhTyrx5oXqrFQto=; b=LXdx5yqqLcJnWWBN7zuiHkvtNt375NhjFwaihfI1bDoMaWUqh7bn0ocXOIKSDUruNM 91c3zN1I0VPb+0P4oTOG5e5isfOY3H47k9zFFW1ZzJTmNE3l7g/2pf2H2mfs9s6yIwdq D281SC7mcvLOq+D1/ec0ho6kwwn3Dj3yMtxQw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hMlz+vn5loEPQvtk2SaQWF8f5Es9FhTyrx5oXqrFQto=; b=lrlUIfft1NTAU3k4Awsg+tCxtu0VJkVodck+f912BNL5QS2Qbu/p8hyYNKa+5JsLCL cyn8szU/3gk3d286zerjoghe/IMI7cr/Rp0oMi6OHEGJgCrN03/ZQotg02mTl3zjSg1s BU8JxJ9D8o11JnTZ93dJlQB+qHDF6tCNHmQ8VYA7ksWajkXqNJ/qeLvKsf1YgKN4RvY+ 8fMHjeXxkKCPl0/INkfkutIgWuHya3xS3hBTv5xpDuZRF/IBvg6obqid9S5tVaEejglJ jiICuuWO4irV/H/VND2M0NHV5yD/2Rkq0IT8vEPRUWqr6JCrPiXZc/XJ1N69OaYPIlSS MyiA== X-Gm-Message-State: AJIora8YqQwhoMAoEd1cQn5B8J0wGSvCNUMdMys87wtvrUOjDAYSItxY LrdczOf46JQnC8f975z8S67/7UmPgZxP7T5ZS8M= X-Received: by 2002:a17:907:28c9:b0:72b:6912:5453 with SMTP id en9-20020a17090728c900b0072b69125453mr26755927ejc.419.1658183709973; Mon, 18 Jul 2022 15:35:09 -0700 (PDT) Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com. [209.85.221.51]) by smtp.gmail.com with ESMTPSA id j4-20020aa7c0c4000000b0043a3b90748asm9249109edp.26.2022.07.18.15.35.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jul 2022 15:35:09 -0700 (PDT) Received: by mail-wr1-f51.google.com with SMTP id bk26so19050757wrb.11 for ; Mon, 18 Jul 2022 15:35:08 -0700 (PDT) X-Received: by 2002:a5d:69c2:0:b0:21d:807c:a892 with SMTP id s2-20020a5d69c2000000b0021d807ca892mr24379660wrw.274.1658183707792; Mon, 18 Jul 2022 15:35:07 -0700 (PDT) MIME-Version: 1.0 References: <20220716230344.239749011@linutronix.de> <87wncauslw.ffs@tglx> <87tu7euska.ffs@tglx> <87o7xmup5t.ffs@tglx> In-Reply-To: From: Linus Torvalds Date: Mon, 18 Jul 2022 15:34:51 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation To: Peter Zijlstra Cc: Thomas Gleixner , LKML , "the arch/x86 maintainers" , Tim Chen , Josh Poimboeuf , Andrew Cooper , Pawan Gupta , Johannes Wikner , Alyssa Milburn , Jann Horn , "H.J. Lu" , Joao Moreira , Joseph Nuzman , Steven Rostedt , Juergen Gross , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 18, 2022 at 2:43 PM Peter Zijlstra wrote: > > FWIW, when I was poking at this last week, I found that -falign-function > only seems to apply to the normal .text section and not to random other > sections with text we create. > > Or rather, I was seeind a lot of unaligned functions that all had custom > sections despite explicitly using the (what I thought was a global) > function alignment toggle. Hmm. This triggers a memory.. I think we may have two different issues at play. One is that I think our linker script only aligns code sections to 8 bytes by default. Grep for ALIGN_FUNCTION. And I think that any .align directive (or .p2align) only aligns relative to that section, so if the section itself wasn't aligned, it doesn't help to have some alignment within the section. I may be wrong. But I can definitely see gcc not aligning functions too, and doing a nm vmlinux | grep ' t ' | grep -v '0 t ' | grep -v '\.cold$' | sort shows a _lot_ of them for me. I think the main cause is that the ACPI code builds with ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA and that '-Os' will disable all function alignment. I think there's a few other places that do that too. I don't see the same effect in my clang build, so I think that -Os behavior is likely gcc-specific. In my clang build, I do see a few unaligned function symbols, but they seem to be all our own assembler ones (eg "nested_nmi") and they seem to be intentional (ie that "nested_nmi" thing is in the middle of the "asm_exc_nmi" function, which is the real thing and which _is_ aligned). Linus