From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C0C5A846C; Thu, 10 Jul 2025 01:57:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752112622; cv=none; b=TIeD5c50jmuF0uKXJ+D63N4yxfI//3XthxMTfEb+oMEqPR5pdOKTf7EONnMPIXLBh3uywfypaWPiDpDZbW9YO9DnSgU+re4gNwirWirDP5nR3xa2f4vtkxh7rfH3uUoNp2GTJ6pf6F5sDjMtDHADk1DTRe81eiuSZXQhVHemxlw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752112622; c=relaxed/simple; bh=V5+0JeybGuGj3hNbNrffhOaKN4FNKIUQicNKhhV6M9M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=omIPSsBs5r7iLg7+sjAVJY9UtCGN9PHUC5gc9uws4aUuGSXXfoAJLKaBa0+DZBMjISWhj0ClhBa3rQ44AlTN0nVkGfO1mDLqwg84gQUwhgcGc70ICfVkH4V0nJYGRKLvvUzm5DX8zGe9+bIYfwvt1qNDMRnY+Hq6beGvjC/DtSY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s36gQ67r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s36gQ67r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B5A6C4CEEF; Thu, 10 Jul 2025 01:57:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752112621; bh=V5+0JeybGuGj3hNbNrffhOaKN4FNKIUQicNKhhV6M9M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=s36gQ67r+HzmWOakvqjLN2Bi+cxAqgCf9b1jm8CeVANKXagOyi4qRCxno997vOt7I npTW9Sqm4fAIHoISBPWcX7vjQIgal5suR6GEB+4EiYf2hwAgwibu53TlZdekzLZBEQ 9ABBQhGaRUZwnPIix2Qtgh30B7PYqrpPimSO1KfrR0HfIEongwbMYk/1onz4hpDV26 GuIsiO8b8UJiiZ9KWrmQ80LhTJRWiOT9thCwXfahXz+KypMzoUnp19aAp8cABbtMDx gSq60cIssEQ+9AYdxjTLFvnKp8xU42OaucaV/Fz2aUcFFHry0HoCkWdrBfNWJs8YVU kLmHPK8kS1RBw== Date: Wed, 9 Jul 2025 18:57:00 -0700 From: Kees Cook To: Ritesh Harjani Cc: Arnd Bergmann , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , "Aneesh Kumar K.V" , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "Gustavo A. R. Silva" , Christoph Hellwig , Marco Elver , Andrey Konovalov , Andrey Ryabinin , Ard Biesheuvel , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Nick Desaulniers , Bill Wendling , Justin Stitt , linux-kernel@vger.kernel.org, x86@kernel.org, kasan-dev@googlegroups.com, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-efi@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kselftest@vger.kernel.org, sparclinux@vger.kernel.org, llvm@lists.linux.dev Subject: Re: [PATCH v2 08/14] powerpc: Handle KCOV __init vs inline mismatches Message-ID: <202507091856.C6510D809A@keescook> References: <20250523043251.it.550-kees@kernel.org> <20250523043935.2009972-8-kees@kernel.org> <87jz662ssp.fsf@gmail.com> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87jz662ssp.fsf@gmail.com> On Sat, May 24, 2025 at 04:13:02PM +0530, Ritesh Harjani wrote: > Kees Cook writes: > > > When KCOV is enabled all functions get instrumented, unless > > the __no_sanitize_coverage attribute is used. To prepare for > > __no_sanitize_coverage being applied to __init functions, we have to > > handle differences in how GCC's inline optimizations get resolved. For > > s390 this requires forcing a couple functions to be inline with > > __always_inline. > > > > Signed-off-by: Kees Cook > > --- > > Cc: Madhavan Srinivasan > > Cc: Michael Ellerman > > Cc: Nicholas Piggin > > Cc: Christophe Leroy > > Cc: Naveen N Rao > > Cc: "Ritesh Harjani (IBM)" > > Cc: "Aneesh Kumar K.V" > > Cc: Andrew Morton > > Cc: > > --- > > arch/powerpc/mm/book3s64/hash_utils.c | 2 +- > > arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c > > index 5158aefe4873..93f1e1eb5ea6 100644 > > --- a/arch/powerpc/mm/book3s64/hash_utils.c > > +++ b/arch/powerpc/mm/book3s64/hash_utils.c > > @@ -409,7 +409,7 @@ static DEFINE_RAW_SPINLOCK(linear_map_kf_hash_lock); > > > > static phys_addr_t kfence_pool; > > > > -static inline void hash_kfence_alloc_pool(void) > > +static __always_inline void hash_kfence_alloc_pool(void) > > { > > if (!kfence_early_init_enabled()) > > goto err; > > diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c > > index 9f764bc42b8c..3238e9ed46b5 100644 > > --- a/arch/powerpc/mm/book3s64/radix_pgtable.c > > +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c > > @@ -363,7 +363,7 @@ static int __meminit create_physical_mapping(unsigned long start, > > } > > > > #ifdef CONFIG_KFENCE > > -static inline phys_addr_t alloc_kfence_pool(void) > > +static __always_inline phys_addr_t alloc_kfence_pool(void) > > { > > phys_addr_t kfence_pool; > > > > I remember seeing a warning msg around .init.text section. Let me dig > that... > > ... Here it is: https://lore.kernel.org/oe-kbuild-all/202504190552.mnFGs5sj-lkp@intel.com/ > > I am not sure why it only complains for hash_debug_pagealloc_alloc_slots(). > I believe there should me more functions to mark with __init here. > Anyways, here is the patch of what I had in mind.. I am not a compiler expert, > so please let me know your thoughts on this. Yeah, this looks good. I'll snag your patch and drop mine. :) -Kees -- Kees Cook