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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 B902DC433DB for ; Tue, 19 Jan 2021 15:13:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7FE352312E for ; Tue, 19 Jan 2021 15:13:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387734AbhASPNE (ORCPT ); Tue, 19 Jan 2021 10:13:04 -0500 Received: from mail.kernel.org ([198.145.29.99]:37468 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390647AbhASOqA (ORCPT ); Tue, 19 Jan 2021 09:46:00 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 08120207FB; Tue, 19 Jan 2021 14:45:02 +0000 (UTC) Date: Tue, 19 Jan 2021 14:45:00 +0000 From: Catalin Marinas To: Vincenzo Frascino Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Will Deacon , Dmitry Vyukov , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Branislav Rankov , Andrey Konovalov Subject: Re: [PATCH v4 5/5] arm64: mte: Inline mte_assign_mem_tag_range() Message-ID: <20210119144459.GE17369@gaia> References: <20210118183033.41764-1-vincenzo.frascino@arm.com> <20210118183033.41764-6-vincenzo.frascino@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210118183033.41764-6-vincenzo.frascino@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 18, 2021 at 06:30:33PM +0000, Vincenzo Frascino wrote: > mte_assign_mem_tag_range() is called on production KASAN HW hot > paths. It makes sense to inline it in an attempt to reduce the > overhead. > > Inline mte_assign_mem_tag_range() based on the indications provided at > [1]. > > [1] https://lore.kernel.org/r/CAAeHK+wCO+J7D1_T89DG+jJrPLk3X9RsGFKxJGd0ZcUFjQT-9Q@mail.gmail.com/ > > Cc: Catalin Marinas > Cc: Will Deacon > Signed-off-by: Vincenzo Frascino > --- > arch/arm64/include/asm/mte.h | 26 +++++++++++++++++++++++++- > arch/arm64/lib/mte.S | 15 --------------- > 2 files changed, 25 insertions(+), 16 deletions(-) > > diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h > index 237bb2f7309d..1a6fd53f82c3 100644 > --- a/arch/arm64/include/asm/mte.h > +++ b/arch/arm64/include/asm/mte.h > @@ -49,7 +49,31 @@ long get_mte_ctrl(struct task_struct *task); > int mte_ptrace_copy_tags(struct task_struct *child, long request, > unsigned long addr, unsigned long data); > > -void mte_assign_mem_tag_range(void *addr, size_t size); > +static inline void mte_assign_mem_tag_range(void *addr, size_t size) > +{ > + u64 _addr = (u64)addr; > + u64 _end = _addr + size; > + > + /* > + * This function must be invoked from an MTE enabled context. > + * > + * Note: The address must be non-NULL and MTE_GRANULE_SIZE aligned and > + * size must be non-zero and MTE_GRANULE_SIZE aligned. > + */ > + do { > + /* > + * 'asm volatile' is required to prevent the compiler to move > + * the statement outside of the loop. > + */ > + asm volatile(__MTE_PREAMBLE "stg %0, [%0]" > + : > + : "r" (_addr) > + : "memory"); > + > + _addr += MTE_GRANULE_SIZE; > + } while (_addr != _end); > +} While I'm ok with moving this function to C, I don't think it solves the inlining in the kasan code. The only interface we have to kasan is via mte_{set,get}_mem_tag_range(), so the above function doesn't need to live in a header. If you do want inlining all the way to the kasan code, we should probably move the mte_{set,get}_mem_tag_range() functions to the header as well (and ideally backed by some numbers to show that it matters). Moving it to mte.c also gives us more control on how it's called (we have the WARN_ONs in place in the callers). -- Catalin 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=-15.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 B159EC433E0 for ; Tue, 19 Jan 2021 14:46:33 +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 712BE21D1B for ; Tue, 19 Jan 2021 14:46:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 712BE21D1B Authentication-Results: mail.kernel.org; dmarc=fail (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=KjEoQ+64+uvRi40NsEewkGDB9wb1kjwl5X8iLZgjpLU=; b=qr5kzrJkUwHlKwjqzgzQwsiQA Lwxvf073p77eIU4TnsWY9TpGFQSpNGOt0FHcT8lZ5wvdKko69uxqRYJ1tWzcI2sYgake4CQRf5ec9 tvmivSk1iXPW5LuuTINYA/jhdZaRNHVqd6m5+iXAYkwmj+wAQj+IyH827FuHbipVJ0ZGhmHZD0fl8 04pFsHFxPiwepa9e4VHaPVBxPST+rpWR2HSl8ibAiTCkDbqCODx/kWwx8xLgfUNZLYTCpUinNatzR tdtII9/xxpH+bWt4U4GyiHfduK34IfwzdvwpkzQCW+EKVWc4rZEU+NJD9xE1Jt86N8i8kkPaNStPG Zccfa3Vqg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l1sFp-0005dz-Jj; Tue, 19 Jan 2021 14:45:09 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l1sFm-0005dP-Jn for linux-arm-kernel@lists.infradead.org; Tue, 19 Jan 2021 14:45:07 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 08120207FB; Tue, 19 Jan 2021 14:45:02 +0000 (UTC) Date: Tue, 19 Jan 2021 14:45:00 +0000 From: Catalin Marinas To: Vincenzo Frascino Subject: Re: [PATCH v4 5/5] arm64: mte: Inline mte_assign_mem_tag_range() Message-ID: <20210119144459.GE17369@gaia> References: <20210118183033.41764-1-vincenzo.frascino@arm.com> <20210118183033.41764-6-vincenzo.frascino@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210118183033.41764-6-vincenzo.frascino@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210119_094506_731657_A12A7CCC X-CRM114-Status: GOOD ( 20.95 ) 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: Branislav Rankov , Marco Elver , Andrey Konovalov , Evgenii Stepanov , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Alexander Potapenko , linux-arm-kernel@lists.infradead.org, Andrey Ryabinin , Will Deacon , Dmitry Vyukov 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, Jan 18, 2021 at 06:30:33PM +0000, Vincenzo Frascino wrote: > mte_assign_mem_tag_range() is called on production KASAN HW hot > paths. It makes sense to inline it in an attempt to reduce the > overhead. > > Inline mte_assign_mem_tag_range() based on the indications provided at > [1]. > > [1] https://lore.kernel.org/r/CAAeHK+wCO+J7D1_T89DG+jJrPLk3X9RsGFKxJGd0ZcUFjQT-9Q@mail.gmail.com/ > > Cc: Catalin Marinas > Cc: Will Deacon > Signed-off-by: Vincenzo Frascino > --- > arch/arm64/include/asm/mte.h | 26 +++++++++++++++++++++++++- > arch/arm64/lib/mte.S | 15 --------------- > 2 files changed, 25 insertions(+), 16 deletions(-) > > diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h > index 237bb2f7309d..1a6fd53f82c3 100644 > --- a/arch/arm64/include/asm/mte.h > +++ b/arch/arm64/include/asm/mte.h > @@ -49,7 +49,31 @@ long get_mte_ctrl(struct task_struct *task); > int mte_ptrace_copy_tags(struct task_struct *child, long request, > unsigned long addr, unsigned long data); > > -void mte_assign_mem_tag_range(void *addr, size_t size); > +static inline void mte_assign_mem_tag_range(void *addr, size_t size) > +{ > + u64 _addr = (u64)addr; > + u64 _end = _addr + size; > + > + /* > + * This function must be invoked from an MTE enabled context. > + * > + * Note: The address must be non-NULL and MTE_GRANULE_SIZE aligned and > + * size must be non-zero and MTE_GRANULE_SIZE aligned. > + */ > + do { > + /* > + * 'asm volatile' is required to prevent the compiler to move > + * the statement outside of the loop. > + */ > + asm volatile(__MTE_PREAMBLE "stg %0, [%0]" > + : > + : "r" (_addr) > + : "memory"); > + > + _addr += MTE_GRANULE_SIZE; > + } while (_addr != _end); > +} While I'm ok with moving this function to C, I don't think it solves the inlining in the kasan code. The only interface we have to kasan is via mte_{set,get}_mem_tag_range(), so the above function doesn't need to live in a header. If you do want inlining all the way to the kasan code, we should probably move the mte_{set,get}_mem_tag_range() functions to the header as well (and ideally backed by some numbers to show that it matters). Moving it to mte.c also gives us more control on how it's called (we have the WARN_ONs in place in the callers). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel