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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29754C433F5 for ; Thu, 16 Dec 2021 10:34:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E4926B0071; Thu, 16 Dec 2021 05:34:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 794B06B0073; Thu, 16 Dec 2021 05:34:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 683946B0074; Thu, 16 Dec 2021 05:34:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 59B576B0071 for ; Thu, 16 Dec 2021 05:34:44 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1E3FA886FE for ; Thu, 16 Dec 2021 10:34:34 +0000 (UTC) X-FDA: 78923298468.28.8A187FC Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf20.hostedemail.com (Postfix) with ESMTP id 552001C0013 for ; Thu, 16 Dec 2021 10:34:31 +0000 (UTC) Received: by mail-qt1-f182.google.com with SMTP id j17so24962004qtx.2 for ; Thu, 16 Dec 2021 02:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=M+0sYl7w0EFJ72TMaAFHyV1NVwE2EB6FQgQgq+6hP5E=; b=R5rs8mLKc9+IweLlPGugdIqRbsaQ+ykrd4Qw0rYiqKo7CBJEMc01G0mkilYP1nCpNr EbfrdFpMNXVrsUCp3Dbq6y+5yK8eGjHDc+5Hdja4rIqou0bGFzJhmnGm39HpAlIYAAOG yxoIVOyRBWaG/a/pCsSOaWPqJLWFaE3H+Yh9ocZKGVjzpg3U0VqYZpAUAre1X8YUrUO9 vEccsaCzWolMC8UYG3MdqFP/YAR7aMSdYrF3R9Fu3ieKV7HGs0qxMUThIQxbt52UOxFX xIB3YRLsjGT09GBoJNNY25C3dd9pHQkrVZit2MRrI2zII4Jw6CrAXvnTmui+4982C1hM t7Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=M+0sYl7w0EFJ72TMaAFHyV1NVwE2EB6FQgQgq+6hP5E=; b=fRIpw3UwBHjVPCRC7j6Xj/+14MpeJp5NQqkSnJVSaiqcafXv67pvmYP+fuQfItJiEW nReagoSxcgNzVOB0tcVLs0pRtc7OXhdvcXofP7WrYB3u6v5mcKfaSSRWexNWSRgu7oIM sh7DJyOqvwrhG3KSF+C017H1IWxpx6snfD3cjjp/35Ke6lhh5sRAwDiMn88thZQT/VJC Tl4CldPPh+BLquF9L3THefhLRfkxY426pfTiTFF7IyLRgn0RsK3rAhnr9QZpsdDcn2Wf IG8ObNityKINxTyXBw91KpqRimcgbuDJtuGFlUgsyWiNRNdimVuy5bQ6OfSjlkcsTO8n sl8A== X-Gm-Message-State: AOAM532kELlOVNgKhvOTKpsMRoe4Qmw8SceXKIdd2dgHVvp2Xwsa6Azr yIW36OZNoL0P0Bxjy1UWnhLFhVjiTvuhkenYU/2V5g== X-Google-Smtp-Source: ABdhPJw0jeWo1ZwgFv58HwTnkU4NU69fnNqT/q0owhKeEurY9FKnfrFrKyeNZuGGVxZtljFxx/Gn0tS3qUqy4vwQFZ8= X-Received: by 2002:a05:622a:2d5:: with SMTP id a21mr16301315qtx.56.1639650872812; Thu, 16 Dec 2021 02:34:32 -0800 (PST) MIME-Version: 1.0 References: <20211214162050.660953-1-glider@google.com> <20211214162050.660953-14-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Thu, 16 Dec 2021 11:33:56 +0100 Message-ID: Subject: Re: [PATCH 13/43] kmsan: add KMSAN runtime core To: Greg Kroah-Hartman Cc: Alexander Viro , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Marco Elver , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 552001C0013 X-Stat-Signature: opbhpzy5w9rx3jfsoitbnzb3r8xdi8ok Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=R5rs8mLK; spf=pass (imf20.hostedemail.com: domain of glider@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1639650871-566917 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 Tue, Dec 14, 2021 at 5:34 PM Greg Kroah-Hartman wrote: > > On Tue, Dec 14, 2021 at 05:20:20PM +0100, Alexander Potapenko wrote: > > This patch adds the core parts of KMSAN runtime and associated files: > > > > - include/linux/kmsan-checks.h: user API to poison/unpoison/check > > the kernel memory; > > - include/linux/kmsan.h: declarations of KMSAN hooks to be referenced > > outside of KMSAN runtime; > > - lib/Kconfig.kmsan: CONFIG_KMSAN and related declarations; > > - Makefile, mm/Makefile, mm/kmsan/Makefile: boilerplate Makefile code= ; > > - mm/kmsan/annotations.c: non-inlineable implementation of KMSAN_INIT= (); > > - mm/kmsan/core.c: core functions that operate with shadow and origin > > memory and perform checks, utility functions; > > - mm/kmsan/hooks.c: KMSAN hooks for kernel subsystems; > > - mm/kmsan/init.c: KMSAN initialization routines; > > - mm/kmsan/instrumentation.c: functions called by KMSAN instrumentati= on; > > - mm/kmsan/kmsan.h: internal KMSAN declarations; > > - mm/kmsan/shadow.c: routines that encapsulate metadata creation and > > addressing; > > - scripts/Makefile.kmsan: CFLAGS_KMSAN > > - scripts/Makefile.lib: KMSAN_SANITIZE and KMSAN_ENABLE_CHECKS macros > > > That's an odd way to write a changelog, don't you think? Agreed. I'll try to concentrate on the functionality instead. Sorry about t= hat. > You need to describe what you are doing here and why you are doing it. > Not a list of file names, we can see that in the diffstat. > > Also, you don't mention you are doing USB stuff here at all. And why > are you doing it here? That should be added in a later patch. You are right, USB is a good example of a stand-alone feature that can be moved to a separate patch. > Break this up into smaller, logical, pieces that add the infrastructure > and build on it. Don't just chop your patches up on a logical-file > boundry, as you are adding stuff in this patch that you do not need for > many more later on, which means it was not needed here. Just to make sure I don't misunderstand - for example for "kmsan: mm: call KMSAN hooks from SLUB code", would it be better to pull the code in mm/kmsan/core.c implementing kmsan_slab_alloc() and kmsan_slab_free() into that patch? I thought maintainers would prefer to have patches to their code separated from KMSAN code, but if it's not true, I can surely fix that. > thanks, > > greg k-h --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg