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 2CCA4C7EE2E for ; Tue, 28 Feb 2023 11:58:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230388AbjB1L6N (ORCPT ); Tue, 28 Feb 2023 06:58:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56376 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229694AbjB1L6K (ORCPT ); Tue, 28 Feb 2023 06:58:10 -0500 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 445652310C for ; Tue, 28 Feb 2023 03:58:09 -0800 (PST) Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4PQwqL0WKnz4x1S; Tue, 28 Feb 2023 22:58:05 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1677585487; bh=T7m6rAKgrT8sjyDmNLKdZltCp4n7kd0f94FIxHvHRGw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=f5n+G1San0GWm4EURNJwqNBX5uB++CKCNw0d4OVqayAOk9X6wJ0cJNyhLbSmkqsf9 I8TJPFTiRl0qOqMUYUC55+bFFECxTuNz91Kw9Ou3qAorl5UorGl+3CtE7vE4BzZvZs tyLvaxkStt6qhxCRxGt1hY9gvWqAkP3cyx831AnNmAdt00vQDCMDvAxAfVYbJ56mwm ScSy6Nwpi94mJ5Iv3P283KF7epzI45yiXTh0JnUJss8Odc3npkdc9osKcGtpxjDwtf Im+tkXG3OdgrSEejGFlh2Y16eZ5woef/IqAPThq/XOLbWzaTSMWupbn8Z9zX27C64f Nz4srrQ/Q4hvQ== From: Michael Ellerman To: Marco Elver , Andrew Morton Cc: Alexander Potapenko , Andrey Ryabinin , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Nicholas Piggin , Christophe Leroy , Liam Howlett , kasan-dev@googlegroups.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Daniel Axtens , kernel test robot Subject: Re: [PATCH mm] kasan, powerpc: Don't rename memintrinsics if compiler adds prefixes In-Reply-To: References: <20230227094726.3833247-1-elver@google.com> <20230227141646.084c9a49fcae018852ca60f5@linux-foundation.org> Date: Tue, 28 Feb 2023 22:58:03 +1100 Message-ID: <87o7peuhmc.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Marco Elver writes: > On Mon, 27 Feb 2023 at 23:16, Andrew Morton wrote: >> >> On Mon, 27 Feb 2023 10:47:27 +0100 Marco Elver wrote: >> >> > With appropriate compiler support [1], KASAN builds use __asan prefixed >> > meminstrinsics, and KASAN no longer overrides memcpy/memset/memmove. >> > >> > If compiler support is detected (CC_HAS_KASAN_MEMINTRINSIC_PREFIX), >> > define memintrinsics normally (do not prefix '__'). >> > >> > On powerpc, KASAN is the only user of __mem functions, which are used to >> > define instrumented memintrinsics. Alias the normal versions for KASAN >> > to use in its implementation. >> > >> > Link: https://lore.kernel.org/all/20230224085942.1791837-1-elver@google.com/ [1] >> > Link: https://lore.kernel.org/oe-kbuild-all/202302271348.U5lvmo0S-lkp@intel.com/ >> > Reported-by: kernel test robot >> > Signed-off-by: Marco Elver >> >> Seems this is a fix against "kasan: treat meminstrinsic as builtins in >> uninstrumented files", so I'll plan to fold this patch into that patch. > > Yes, that looks right. > > If a powerpc maintainer could take a quick look as well would be good. The patch looks OK to me. It builds for various configs and I did a few test boots with KASAN enabled, everything seems normal. Acked-by: Michael Ellerman (powerpc) > The maze of memcpy/memmove/memset definitions and redefinitions isn't > the simplest - I hope in a few years we can delete all the old code > (before CC_HAS_KASAN_MEMINTRINSIC_PREFIX), and let the compilers just > "do the right thing". Yeah that would be nice. cheers