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=-24.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 99960C433DB for ; Wed, 3 Feb 2021 15:51:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E8ED664E3D for ; Wed, 3 Feb 2021 15:51:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8ED664E3D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 50E596B0071; Wed, 3 Feb 2021 10:51:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BF2F6B0072; Wed, 3 Feb 2021 10:51:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3889D6B0073; Wed, 3 Feb 2021 10:51:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id 239866B0071 for ; Wed, 3 Feb 2021 10:51:22 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BF8F08249980 for ; Wed, 3 Feb 2021 15:51:21 +0000 (UTC) X-FDA: 77777395962.10.home72_1a04971275d4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 9F22716A047 for ; Wed, 3 Feb 2021 15:51:21 +0000 (UTC) X-HE-Tag: home72_1a04971275d4 X-Filterd-Recvd-Size: 8217 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Wed, 3 Feb 2021 15:51:21 +0000 (UTC) Received: by mail-wr1-f49.google.com with SMTP id p15so24875415wrq.8 for ; Wed, 03 Feb 2021 07:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=u/vTmytfnHf8bSBtRdC4NPN+aY/KtT7liekrT8jCTRw=; b=opmr3FHE2TNxylL9qrL3VCPPX/vR+oTiZPV3+yNJ3oDsbprIIJqpAyXpXpxF1knDgn GhSrc8eVFebQUjT4pgW3MEE/vmbk+b2gQ/q2qDnCQ824F8bIfBfhWvk0DpqxabeyO5s7 ziy/ZjiKZxTCS6Lhce5scCX2JJIhHpVuLZQga1SxEJ8tco5VkP1OQ5X3ayaRzFebVpfh u23awiGivr2HiDWTH2UbctnGbpPRy5EMqP5UbV3sTpI1KfdnlE9Ln6jQYGfXjMvvtgt7 jN5OyNhhYzi4QxXtQHgd0G4ALm2BHi4MrHGUHSTAovAUWQ9hoNLX3rqZoiZnqj7cBbN5 KxQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=u/vTmytfnHf8bSBtRdC4NPN+aY/KtT7liekrT8jCTRw=; b=PNMYh723ajyuQfcZHmOTT1sQCfQvQ5n17Y0j/FMalDHET+569CAnJBvAr0n2JbhhkB 1/m9LGUjH2e2JE7Jwvyaek6Fv+0I55q1XYsI06iwF8HKS2YjYnDXeWqRmxW8fAxobCCZ mOWCImgP9cDNRmkyyJUVjakI+ubu7ll7FY7Dgg9ZhZ9i5IJiXAa8Q7+vKtdmKb95mJ8K mQ1LDlirRKrtP/nw2amhy0o2cyPpsR2KpLKQuh4ojR4Kh3SPrCQkLI5Cpvd94UHZDtPp qOw0dWzznnx2uOvVbFAtSQo6NmfOxMtfA1Fwfow7wvaB1ha/bUZIyYL+c2noSDaRbdlP G4mw== X-Gm-Message-State: AOAM53279dlDneLELtvAfxvLfeTJ6IaSLpo/vm08tmRVAqeVmmWu6pgl GsQLfDyRaCrymgu/R8ZwlNidgw== X-Google-Smtp-Source: ABdhPJzdB80SJfASSySTyybBpaCA+sAR5IcghRfo+MI3RzaziLqWjUt93++mgIC6ytnuaLUl0UBx2g== X-Received: by 2002:a5d:5686:: with SMTP id f6mr4193118wrv.257.1612367479798; Wed, 03 Feb 2021 07:51:19 -0800 (PST) Received: from elver.google.com ([2a00:79e0:15:13:b1de:c7d:30ce:1840]) by smtp.gmail.com with ESMTPSA id p9sm4481682wrj.11.2021.02.03.07.51.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Feb 2021 07:51:18 -0800 (PST) Date: Wed, 3 Feb 2021 16:51:13 +0100 From: Marco Elver To: Andrey Konovalov Cc: Catalin Marinas , Vincenzo Frascino , Dmitry Vyukov , Alexander Potapenko , Andrew Morton , Will Deacon , Andrey Ryabinin , Peter Collingbourne , Evgenii Stepanov , Branislav Rankov , Kevin Brodsky , kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 11/12] kasan: always inline HW_TAGS helper functions Message-ID: References: <05a45017b4cb15344395650e880bbab0fe6ba3e4.1612208222.git.andreyknvl@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05a45017b4cb15344395650e880bbab0fe6ba3e4.1612208222.git.andreyknvl@google.com> User-Agent: Mutt/2.0.2 (2020-11-20) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 01, 2021 at 08:43PM +0100, Andrey Konovalov wrote: > Mark all static functions in common.c and kasan.h that are used for > hardware tag-based KASAN as __always_inline to avoid unnecessary > function calls. > > Signed-off-by: Andrey Konovalov Does objtool complain about any of these? I'm not sure this is unconditionally a good idea. If there isn't a quantifiable performance bug or case where we cannot call a function, perhaps we can just let the compiler decide? More comments below. > --- > mm/kasan/common.c | 13 +++++++------ > mm/kasan/kasan.h | 6 +++--- > 2 files changed, 10 insertions(+), 9 deletions(-) > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c > index 5691cca69397..2004ecd6e43c 100644 > --- a/mm/kasan/common.c > +++ b/mm/kasan/common.c > @@ -279,7 +279,8 @@ void __kasan_poison_object_data(struct kmem_cache *cache, void *object) > * based on objects indexes, so that objects that are next to each other > * get different tags. > */ > -static u8 assign_tag(struct kmem_cache *cache, const void *object, bool init) > +static __always_inline u8 assign_tag(struct kmem_cache *cache, > + const void *object, bool init) This function might be small enough that it's fine. > { > if (IS_ENABLED(CONFIG_KASAN_GENERIC)) > return 0xff; > @@ -321,8 +322,8 @@ void * __must_check __kasan_init_slab_obj(struct kmem_cache *cache, > return (void *)object; > } > > -static bool ____kasan_slab_free(struct kmem_cache *cache, void *object, > - unsigned long ip, bool quarantine) > +static __always_inline bool ____kasan_slab_free(struct kmem_cache *cache, > + void *object, unsigned long ip, bool quarantine) > { Because ____kasan_slab_free() is tail-called by __kasan_slab_free() and __kasan_slab_free_mempool(), there should never be a call (and if there is we need to figure out why). The additional code-bloat and I-cache pressure might be worse vs. just a jump. I'd let the compiler decide. > u8 tag; > void *tagged_object; > @@ -366,7 +367,7 @@ bool __kasan_slab_free(struct kmem_cache *cache, void *object, unsigned long ip) > return ____kasan_slab_free(cache, object, ip, true); > } > > -static bool ____kasan_kfree_large(void *ptr, unsigned long ip) > +static __always_inline bool ____kasan_kfree_large(void *ptr, unsigned long ip) > { This one is tail-called by __kasan_kfree_large(). The usage in __kasan_slab_free_mempool() is in an unlikely branch. > if (ptr != page_address(virt_to_head_page(ptr))) { > kasan_report_invalid_free(ptr, ip); > @@ -461,8 +462,8 @@ void * __must_check __kasan_slab_alloc(struct kmem_cache *cache, > return tagged_object; > } > > -static void *____kasan_kmalloc(struct kmem_cache *cache, const void *object, > - size_t size, gfp_t flags) > +static __always_inline void *____kasan_kmalloc(struct kmem_cache *cache, > + const void *object, size_t size, gfp_t flags) > { Also only tail-called. > unsigned long redzone_start; > unsigned long redzone_end; > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h > index 2f7400a3412f..d5fe72747a53 100644 > --- a/mm/kasan/kasan.h > +++ b/mm/kasan/kasan.h > @@ -321,7 +321,7 @@ static inline u8 kasan_random_tag(void) { return 0; } > > #ifdef CONFIG_KASAN_HW_TAGS > > -static inline void kasan_poison(const void *addr, size_t size, u8 value) > +static __always_inline void kasan_poison(const void *addr, size_t size, u8 value) > { > addr = kasan_reset_tag(addr); > > @@ -337,7 +337,7 @@ static inline void kasan_poison(const void *addr, size_t size, u8 value) > hw_set_mem_tag_range((void *)addr, size, value); > } > > -static inline void kasan_unpoison(const void *addr, size_t size) > +static __always_inline void kasan_unpoison(const void *addr, size_t size) > { Not sure about these 2. They should be small, but it's hard to say what is ideal on which architecture. > u8 tag = get_tag(addr); > > @@ -354,7 +354,7 @@ static inline void kasan_unpoison(const void *addr, size_t size) > hw_set_mem_tag_range((void *)addr, size, tag); > } > > -static inline bool kasan_byte_accessible(const void *addr) > +static __always_inline bool kasan_byte_accessible(const void *addr) This function feels like a macro and if the compiler uninlined it, we could argue it's a bug. But not sure if we need the __always_inline, unless you've seen this uninlined. > { > u8 ptr_tag = get_tag(addr); > u8 mem_tag = hw_get_mem_tag((void *)addr); > -- > 2.30.0.365.g02bc693789-goog >