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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C3874C433EF for ; Thu, 2 Dec 2021 10:45:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=O04cU5WE8wcR64WmXMxIxuT7WdFCU1tQs3uO6K650rA=; b=VJ94I2/VbiDlqY hAYKJUjNIrv4FExRCF4EB3EA6bWDCw2MP+TzGcGmxbptVQ2hCCWpfjKP9m4GDzrEv5uegdLGb/13y +3roHJLc1ZswuEc8pWSKTNx56flLylPLrBSO2ToFiNYgpbBwqsH1PJUUB4RySroNEC3NeUIE/4o5r frpDyhEHzcEHtbKWKz99pSepF8kFQLykwynWaUhRqnQOutvDIHYIKBG+Xauj1cewUMbU0olcp+aju pdKq2R9luAqJ+bQlVjt7dYNGRIY+/e/j1va/16sF2/INRcS04JBE/vv/qWSyPfBgnwBDz/SUeTfwc hBJkIJNNjXHuxlZaLWeQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1msjZ8-00BrUk-18; Thu, 02 Dec 2021 10:43:50 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1msjZ3-00BrUO-Q5 for linux-arm-kernel@lists.infradead.org; Thu, 02 Dec 2021 10:43:47 +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 1136D142F; Thu, 2 Dec 2021 02:43:43 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.65.131]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 342783F7D7; Thu, 2 Dec 2021 02:43:42 -0800 (PST) Date: Thu, 2 Dec 2021 10:43:39 +0000 From: Mark Rutland To: Mark Brown Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org Subject: Re: [PATCH] arm64: ftrace: add missing BTIs Message-ID: References: <20211129135709.2274019-1-mark.rutland@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211202_024345_939622_B60766C5 X-CRM114-Status: GOOD ( 26.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Mon, Nov 29, 2021 at 05:48:46PM +0000, Mark Brown wrote: > On Mon, Nov 29, 2021 at 05:37:51PM +0000, Mark Rutland wrote: > > On Mon, Nov 29, 2021 at 04:50:39PM +0000, Mark Brown wrote: > > > > > +#ifdef BTI_C > > > > + BTI_C > > > > +#endif > > > > The ifdefs here feel ugly enough that it might be worth doing that right > > > now TBH. I'm trying to think of any cases where we might also need a > > > BTI J but nothing springs to mind right now. > > > Agreed on the ugliness -- I'd like to revisit that with some related > > cleanup/improvement to our existing SYM_*() macros. I just didn't want to do > > that as a prerequisite for the fix as it'd make backports painful, e.g. by > > creating a dependency on commit: > > > 1cbdf60bd1b74e39 ("kasan: arm64: support specialized outlined tag mismatch checks") > > > ... which uses the ifdef pattern above. > > Ugh, that's not great. But yes, backporting was why I did the Reviwed-by. Sure, and thanks for that! > If we knew the names we were going for it'd be easy enough to add a new > SYM_CODE_ varaint without introducing dependencies but that might be > getting ahead of things. > > > I'm also not sure what naming/structure we'd like, or whether it's simpler to > > unconditionally define BTI_C. > > The unconditional definition seems like it might be neater as a > minimally intrusive thing for backporting, we can always refactor later. The problem with that is that for consistency we should remove the ifdeferry from the kasan trampoline at the same time, which either means an unnecessary dependency as above, or splitting this into three patches, one of which should not be backported. Given that, I think that as-is this is the simplest form for backporting. I completely agree the ifdeferry is ugly, and I do intend to follow up on that regardless. If you feel strongly that we should get rid of that now, I can spin a v2 with a second patch to clean that up; otherwise I'll do that as part of a later series. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel