Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp758085pxb; Fri, 28 Jan 2022 09:19:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJz0F0kQN3+cucjQaaD6QkAuo2nkLvuOud9oSd74sjb69X0zzt2K3p0ig4MC7MIwiOGfLHmY X-Received: by 2002:a63:b207:: with SMTP id x7mr7266185pge.392.1643390360067; Fri, 28 Jan 2022 09:19:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643390360; cv=none; d=google.com; s=arc-20160816; b=VEMtQWzWC9FX/gAnzDzRNYawSvkmQBW7fuBwYA7PSKlmHS8IonaqvINmkfGzUo94d4 WJljUtqi/5WmC8dEFBWyrqqtvWPaxAU/lreJLQxo8bk6LsM0viRmff8ipoGLCyZlPiGm leKoDcqAHsaVjyHLCDIUGimoSVhYpH/MwZWc7wK00pGeHeh73iTdpzch9qgjwKSMsRjA /CdmldPjTh+gSgxYNm46u0k2lmQNbwzpcU8amrpKxHIeiFkMehzpe10Ft85FPHTad3EC 2pIF4C0ug/Tl1gpOlrf21g2Y+UOyijoPFxo33DGF7yNAB7OsDcxD44IUdGbLubEmXf9I WtJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:from:cc:content-transfer-encoding :mime-version:message-id:date:subject:dkim-signature; bh=pS6oAPlQasQLltOWbX6ybr6410G9JsawVRKiZZSuto0=; b=lr8zCmTeIYa4C26WfrjGLxwkfm4IpSSU0cgJQHh3NrxV8EhPX2wtgRzHdCOOTRqUPw wxH7yS9foknyk5Acwk3/8Opd+yPtIslV4oJ4RyLRJ87uyp2LCAPhpuxAD7jnAoWaF9BI m/9OA7oAQnbtjC7rKOnv8bLrJ0QvUrvwzdyPPK29K4YyIjKnDIFvCYEzBJ9+uHWCLIiR ly2w536CJvpAPN2lEg4nYCxyXZqdNWAaFHX1ZiNty9dL56hEHyYyxzXfj88N8xZE3TzP ClAn2iyvVXDPDgEMYz0Q3KWHxmezaGJNymj0c7xVmroiqRkWyn8Dzfk+SjgaIOc4MyRj O1zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=OkmBR46i; 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 m13si5593593pls.622.2022.01.28.09.19.07; Fri, 28 Jan 2022 09:19:20 -0800 (PST) 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; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=OkmBR46i; 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 S1343994AbiA0UDR (ORCPT + 99 others); Thu, 27 Jan 2022 15:03:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343795AbiA0UDC (ORCPT ); Thu, 27 Jan 2022 15:03:02 -0500 Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83C60C061747 for ; Thu, 27 Jan 2022 12:03:02 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id p37so3796697pfh.4 for ; Thu, 27 Jan 2022 12:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=subject:date:message-id:mime-version:content-transfer-encoding:cc :from:to; bh=pS6oAPlQasQLltOWbX6ybr6410G9JsawVRKiZZSuto0=; b=OkmBR46itpSo80eYP7SfR78XlDnMDrL9T8FDPQBDH5rBgiD3BZFfwLp2IIx2tdkHR+ ttRdpr4UVF+iNyhTIs3m0ikyxmU9eeIljF9uOY9Wc2sJLPWeE3QoI2R21yFiy2C4hYY7 qP+0Cueu8u3d84NnxZgzByglJXfgi37r0teIb2DzgVYRuND/lMRdW3Myoloks8Lc6IR2 a4SRgnrJi5GxFgixdCQnkHAwOVTjduufc9hxgByV58qNLUFcYCziJdvmlF2DMzSzc5Ax mE1T78oc8dnShG9T0WwD8JfGPgAQnfc03kPCxAzDENXCdRj7VHYVAj942yBXtMeCxx1w 7inQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:date:message-id:mime-version :content-transfer-encoding:cc:from:to; bh=pS6oAPlQasQLltOWbX6ybr6410G9JsawVRKiZZSuto0=; b=yEZtfskgrdvohPgcpnhXfBFQgZ4UjtClA20QBo4bk9h7HsrVE1TwtC4gFIQWh1U+f1 5tMBISS26qUx1gWK/ivSzWFrX2I9KDTqTCsPCXagL4Q8pglJLMisW0hUduM6Uxw75B5Z PbFYFef+IDU9A+kPJNwBu5ZyqANEdaxiCVHWkR4InkflyTY3vUVhk1PebmbPhdFtGnQI f5d3dfW2Ac0YxVnlIKrHJ72tSI4AIpmojmMJRWkjXQW9mSyeBEXH7MVGIasSPUGJLLMh Fgs4Dph6ZhYNCRX7hawyg0tsK+bvVsGqi0HnhPGCidmEobbjKGYeQWuefApTjVIgZCc0 ZOMg== X-Gm-Message-State: AOAM532i8ri4LUzufl5KMJD4anpSn49CoYCbWtunyVUO++bz5QK6P5D1 1cydXvr2ZmURejqBDWHNmMCwUA== X-Received: by 2002:a62:8fcb:: with SMTP id n194mr4258239pfd.29.1643313782059; Thu, 27 Jan 2022 12:03:02 -0800 (PST) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id s2sm20501253pgf.56.2022.01.27.12.03.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Jan 2022 12:03:01 -0800 (PST) Subject: [PATCH] RISC-V: Prevent sbi_ecall() from being inlined Date: Thu, 27 Jan 2022 11:55:55 -0800 Message-Id: <20220127195554.15705-1-palmer@rivosinc.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: Paul Walmsley , Palmer Dabbelt , aou@eecs.berkeley.edu, anup@brainfault.org, Atish Patra , jszhang@kernel.org, vincent.chen@sifive.com, sunnanyong@huawei.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Atish Patra , Palmer Dabbelt , stable@vger.kernel.org From: Palmer Dabbelt To: linux-riscv@lists.infradead.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Palmer Dabbelt The SBI spec defines SBI calls as following the standard calling convention, but we don't actually inform GCC of that when making an ecall. Unfortunately this does actually manifest for the more complex SBI call wrappers, for example sbi_s, for example sbi_send_ipi_v02() uses t1. This patch just marks sbi_ecall() as noinline, which implicitly enforces the standard calling convention. Fixes : b9dcd9e41587 ("RISC-V: Add basic support for SBI v0.2") Cc: stable@vger.kernel.org Reported-by: Atish Patra Signed-off-by: Palmer Dabbelt --- This is more of a stop-gap fix than anything else, but it's small enough that it should be straight-forward to back port to stable. This bug has existed forever, in theory, but none of this was specified in SBI-0.1 so the backport to the introduction of 0.2 should be sufficient. No extant versions OpenSBI or BBL will manifest issues here, as they save all registers, but the spec is quite explicit so we're better off getting back in line sooner rather than later. There'll be some marginal performance impact here. I'll send a follow-on to clean up the SBI call wrappers in a way that allows inlining without violating the spec, but that'll be a bigger change and thus isn't really suitable for stable. --- arch/riscv/kernel/sbi.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c index f72527fcb347..7be586f5dc69 100644 --- a/arch/riscv/kernel/sbi.c +++ b/arch/riscv/kernel/sbi.c @@ -21,6 +21,11 @@ static int (*__sbi_rfence)(int fid, const struct cpumask *cpu_mask, unsigned long start, unsigned long size, unsigned long arg4, unsigned long arg5) __ro_after_init; +/* + * This ecall stub can't be inlined because we're relying on the presence of a + * function call to enforce the calling convention. + */ +noinline struct sbiret sbi_ecall(int ext, int fid, unsigned long arg0, unsigned long arg1, unsigned long arg2, unsigned long arg3, unsigned long arg4, -- 2.34.1