From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9E69C433DF for ; Wed, 24 Jun 2020 13:46:18 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A635C20857 for ; Wed, 24 Jun 2020 13:46:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nLMolL4J" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A635C20857 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=N1hUJ3f9g2BeV7ykBWs91VbCyJC9ne3z3UFG/EaUQzs=; b=nLMolL4JAZjk8GZfbvSpMmuvG yYRgK+BTNL+FCzhP8rOmJkv9HtXbCNhX7Qb34nExWP2mP6Q52ovfvqP8hTeYWR/F7lAokzxgGkOZr Y231xG3b/3XueYC6M2vcr1xCdgRYViAg1mj7bSK5wE/8e0FytfGRcOxaDxqQ+eqQOFER8Q0Ltia/t lFwiuffc/kAslg3ov83h6Kc/BJ7uiWwTYxrXvK8QDizbhQWJJbTwT43IM28p0wYqvuGyx6tp5PBAA ib+zLMjMX2pgX32K508xMB5wkmL76BCEahWBY6oGquKwzi32FxpTR2Gp5YWjwOxwbWL3EWFNP5OLv qsAmGm/Jw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo5hX-0005ez-Qu; Wed, 24 Jun 2020 13:44:31 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo5hU-0005eA-F8 for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 13:44:29 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 092781F1; Wed, 24 Jun 2020 06:44:28 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 23C603F6CF; Wed, 24 Jun 2020 06:44:27 -0700 (PDT) Date: Wed, 24 Jun 2020 14:44:25 +0100 From: Dave Martin To: Mark Brown Subject: Re: [PATCH] arm64: Don't insert a BTI instruction at inner labels Message-ID: <20200624134424.GE25945@arm.com> References: <20200624112253.1602786-1-jean-philippe@linaro.org> <20200624132114.GB5472@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200624132114.GB5472@sirena.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: maz@kernel.org, Jean-Philippe Brucker , will@kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jun 24, 2020 at 02:21:14PM +0100, Mark Brown wrote: > On Wed, Jun 24, 2020 at 01:22:54PM +0200, Jean-Philippe Brucker wrote: > > > It turns out we don't currently need the BTI landing pads inserted by > > SYM_INNER_LABEL: > > > * ftrace_call and ftrace_graph_call are only used for runtime patching > > of the active tracer. The patched code is not reached from a branch. > > * install_el2_stub is reached from a CBZ instruction, which doesn't > > change PSTATE.BTYPE. > > * __guest_exit is reached from B instructions in the hyp-entry vectors, > > which aren't subject to BTI checks either. > > > Remove the BTI annotation from SYM_INNER_LABEL. > > This fixes things for now but it feels like it's going to be fragile in > the long run since inner labels are a bit of a wild west in terms of how > they're going to be referenced - I can't think of a better solution at > this level though :( > > Reviewed-by: Mark Brown Since inner labels requiring landing pads are going to be the exception rather than the rule, perhaps we can introduce a different macro for this. It feels arch-specific to me (indeed, inner labels are kind of arch-specific, since they're inevitably in the middle of some asm that is unlikely to be handled by core code). Do we know of any code that requires landing pads on inner labels? The uaccess fault stuff probably doesn't, because the error path is reached via ERET. I wondered about the suspend/resume code in sleep.S, but I don't see any inner labels in there. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel