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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F932CA0EC9 for ; Mon, 11 Sep 2023 21:11:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239896AbjIKVGh (ORCPT ); Mon, 11 Sep 2023 17:06:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235555AbjIKI5d (ORCPT ); Mon, 11 Sep 2023 04:57:33 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E2311BE for ; Mon, 11 Sep 2023 01:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=LyggSFNgiy14BwIsDV/0K7QQu/1ltroH4K6t5ZXh5Ko=; b=KynaWtg4Ji1mqWYGq5dur9t/Y+ E+1k3GfenBxgLToV59RYvKzPzAvJkUEL1pWHhlI/xwgf6Ri0egTBJih9teF65YcC9rgFu2/n3qve/ 6slJk/uLntE79CQfZryu3e0oewX/IFH4q1zToOqquqrivvO3CD6Atk0rD7V4bt1JbAyaAg/DMc+a8 Ew5iQPhcCoPl4PQx3/ynBhRDx8Baiq3TqdO36SFBAceY6tixLmIulmF8ysuW1muiWLz2utEM049D4 GxzeqrdK1EDoaDQJPJFN+Z3crp6dfW4vLUFMhiWMAV2slUDPwFMgY6w5z/m/1nm2vLPDONedlsOmg Gml0+ZZw==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1qfcii-004rWA-1F; Mon, 11 Sep 2023 08:56:38 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 7B134300321; Mon, 11 Sep 2023 10:56:37 +0200 (CEST) Date: Mon, 11 Sep 2023 10:56:37 +0200 From: Peter Zijlstra To: Vincent Whitchurch Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Frederic Weisbecker , "Rafael J. Wysocki" , Richard Weinberger , Anton Ivanov , Johannes Berg , linux-um@lists.infradead.org, Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, kernel@axis.com Subject: Re: [PATCH] x86: Fix build of UML with KASAN Message-ID: <20230911085637.GA9098@noisy.programming.kicks-ass.net> References: <20230609-uml-kasan-v1-1-5fac8d409d4f@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230609-uml-kasan-v1-1-5fac8d409d4f@axis.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 09, 2023 at 01:18:54PM +0200, Vincent Whitchurch wrote: > Building UML with KASAN fails since commit 69d4c0d32186 ("entry, kasan, > x86: Disallow overriding mem*() functions") with the following errors: > > $ tools/testing/kunit/kunit.py run --kconfig_add CONFIG_KASAN=y > ... > ld: mm/kasan/shadow.o: in function `memset': > shadow.c:(.text+0x40): multiple definition of `memset'; > arch/x86/lib/memset_64.o:(.noinstr.text+0x0): first defined here > ld: mm/kasan/shadow.o: in function `memmove': > shadow.c:(.text+0x90): multiple definition of `memmove'; > arch/x86/lib/memmove_64.o:(.noinstr.text+0x0): first defined here > ld: mm/kasan/shadow.o: in function `memcpy': > shadow.c:(.text+0x110): multiple definition of `memcpy'; > arch/x86/lib/memcpy_64.o:(.noinstr.text+0x0): first defined here > > If I'm reading that commit right, the !GENERIC_ENTRY case is still > supposed to be allowed to override the mem*() functions, so use weak > aliases in that case. > > Fixes: 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions") > Signed-off-by: Vincent Whitchurch > --- > arch/x86/lib/memcpy_64.S | 4 ++++ > arch/x86/lib/memmove_64.S | 4 ++++ > arch/x86/lib/memset_64.S | 4 ++++ > 3 files changed, 12 insertions(+) > > diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S > index 8f95fb267caa7..5dc265b36ef0b 100644 > --- a/arch/x86/lib/memcpy_64.S > +++ b/arch/x86/lib/memcpy_64.S > @@ -40,7 +40,11 @@ SYM_TYPED_FUNC_START(__memcpy) > SYM_FUNC_END(__memcpy) > EXPORT_SYMBOL(__memcpy) > > +#ifdef CONFIG_GENERIC_ENTRY > SYM_FUNC_ALIAS(memcpy, __memcpy) > +#else > +SYM_FUNC_ALIAS_WEAK(memcpy, __memcpy) > +#endif > EXPORT_SYMBOL(memcpy) > > SYM_FUNC_START_LOCAL(memcpy_orig) Urgh... Can we use CONFIG_UML here to clarify things? It's a bit of a bother UML is diverging to much, but oh well.