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 0D9ABC678D4 for ; Thu, 2 Mar 2023 15:17:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229987AbjCBPRx (ORCPT ); Thu, 2 Mar 2023 10:17:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50608 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229506AbjCBPRu (ORCPT ); Thu, 2 Mar 2023 10:17:50 -0500 Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B61B5497EC for ; Thu, 2 Mar 2023 07:17:49 -0800 (PST) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-536bbe5f888so432611977b3.8 for ; Thu, 02 Mar 2023 07:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=swy0Vvp7k1UShoRmUJ7j46CPAn/D6prvkxRY/qzs/SE=; b=CF2YWaUfaNqcOG3qLv84WuxL0ySDJynMHCuWXjDb6SBI6/hv9XsBfe7dnNpWQ75sYt RUBUbfEpveBvA3RMYD7fBkKlwx27eOJnrBYxHupNj2G/pgsT+ygbEk5Thhnk9x/7OB0v rn3/Q4c88hafo04aQczG5eI7ps3iCD1jgVntZ+0nTpDmxcKweFS4aCssk0rjGWPobWi8 chTNOSmRE3M8Lj3Dx5DVEQr6l4FxGjn5YU3xDAc65gIh47YSl1p+IY8CT4iqLvvyfRVO kNhOOfR+j6eQ9KlDg1HKESImS6URfOLplYCbFVLs1gqTbMnTdGuCmwXEvNTaFUFbCVDt 6h/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=swy0Vvp7k1UShoRmUJ7j46CPAn/D6prvkxRY/qzs/SE=; b=0o2kiwIf0JO6vwjCFrQvtesVr9vu0hyZb5otv+TFOsFqGCRcbcs2WIPRjKRXuu6LHc wOY06LyIbxvWoSnaXGPUgbVMyejHHf68JsJe+QATRn+AIhMmUMy+TFXEaGySmfvvBheu WRax87ag2plDAwkiSSde2zkfQYbyyWovFZTIm/KRtEbPxKriumOclLYJaeoFLZ0zBMJH pVkvLUq5juSAse2CQJaTzWxvkcPQHrmI4ZntbvGvtmY26S8i5hfp4XB1hBgwiqY18VB+ NSzPzbgXZyJEEnb+iremGj0BIJWnRT8S7jZNhFv+VJEj+6Km5M5EY3PjMs0qT08G/MBA BuDg== X-Gm-Message-State: AO0yUKWrNDqTCUiFUxSkDejKmOBx9JfZHRJyY/BKvFwRzZQkC/lrLcTY E8g9DGSh4ld/H4Pc3biPyB4Z8OmUIqM9rXk8Sb26SDCGV43Uut5I X-Google-Smtp-Source: AK7set+3VrU1WkPMjDY7pE36z7iW24+fggQzrZ99elu49Vgl4quWaYlSQGHbSXoNkwjoVUmRjlbIWCDcD/wyj3OoPO8= X-Received: by 2002:a81:ad58:0:b0:52a:9f66:80c6 with SMTP id l24-20020a81ad58000000b0052a9f6680c6mr6418676ywk.9.1677770268490; Thu, 02 Mar 2023 07:17:48 -0800 (PST) MIME-Version: 1.0 References: <20230301143933.2374658-1-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Thu, 2 Mar 2023 16:17:11 +0100 Message-ID: Subject: Re: [PATCH 1/4] x86: kmsan: Don't rename memintrinsics in uninstrumented files To: Marco Elver Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, dave.hansen@linux.intel.com, hpa@zytor.com, akpm@linux-foundation.org, dvyukov@google.com, nathan@kernel.org, ndesaulniers@google.com, kasan-dev@googlegroups.com, Kees Cook Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 2, 2023 at 4:13=E2=80=AFPM Marco Elver wrote= : > > On Thu, 2 Mar 2023 at 15:28, Alexander Potapenko wrot= e: > > > > On Thu, Mar 2, 2023 at 12:14=E2=80=AFPM Marco Elver = wrote: > > > > > > On Wed, 1 Mar 2023 at 15:39, Alexander Potapenko = wrote: > > > > > > > > KMSAN should be overriding calls to memset/memcpy/memmove and their > > > > > > You mean that the compiler will override calls? > > > All supported compilers that have fsanitize=3Dkernel-memory replace > > > memintrinsics with __msan_mem*() calls, right? > > > > Right. Changed to: > > > > KMSAN already replaces calls to to memset/memcpy/memmove and their > > __builtin_ versions with __msan_memset/__msan_memcpy/__msan_memmove in > > instrumented files, so there is no need to override them. > > But it's not KMSAN - KMSAN is the combined end result of runtime and > compiler - in this case we need to be specific and point out it's the > compiler that's doing it. There is no code in the Linux kernel that > does this replacement. Agreed. I'll replace with "clang -fsanitize=3Dkernel-memory"