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 X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17102C55ABD for ; Thu, 12 Nov 2020 19:52:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 81D122085B for ; Thu, 12 Nov 2020 19:52:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="LyRcRhjy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 81D122085B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0B71B6B0068; Thu, 12 Nov 2020 14:52:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 08C8E6B006C; Thu, 12 Nov 2020 14:52:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE5E56B006E; Thu, 12 Nov 2020 14:52:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0159.hostedemail.com [216.40.44.159]) by kanga.kvack.org (Postfix) with ESMTP id C05BE6B0068 for ; Thu, 12 Nov 2020 14:52:26 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6BEBC8249980 for ; Thu, 12 Nov 2020 19:52:26 +0000 (UTC) X-FDA: 77476813092.27.smile79_60049bb27309 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 478123D663 for ; Thu, 12 Nov 2020 19:52:26 +0000 (UTC) X-HE-Tag: smile79_60049bb27309 X-Filterd-Recvd-Size: 5433 Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Thu, 12 Nov 2020 19:52:25 +0000 (UTC) Received: by mail-oi1-f195.google.com with SMTP id q206so7701765oif.13 for ; Thu, 12 Nov 2020 11:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ku38Ht+p6L/Qff47Jz/ZEW3Rmq7V+uR73aOdxjfDMS0=; b=LyRcRhjy9O9Onai4KalpJMvwS0HgVos89lh0h/DSDaGHtHndNCyX4CxpDLuicoH2FB KwsEF5KZpU7cm359GOxKOSjFIw0SWUVglwF3TQFc7+Pw+EXy4jIEQsJd/mS7Y3iYsO90 9olyGHAl8rLyBIWdFeoBNytZEYeANkpdla2eH0ct5Hjqk2nnB90HcqfO1cILYDWgXN61 3KxG7dv6LgA+XUz/pRIEN5HB8/Un/Yn/R0KPLGJ6mSqEnBAc6HIbkTEYsUY8QFunQOMA HLXF0ccMMJuHrStP7aFBzIh2HIqpbFxBa7mW74b6m+jhyjx2hxd3q+3PeGlS08iLoKwN m65Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ku38Ht+p6L/Qff47Jz/ZEW3Rmq7V+uR73aOdxjfDMS0=; b=EZzdb/SgBuN+X8gMJm7DGhybEQCGssfS+O3mdDrL2bm06lzCkpQqR7/QsRvAc3rrnj dNfS6IiMSiUxGDvfVZ1l4FXXAvyMvjVQchWK4nHxm0COj0LpkT4uqfJPdB3nYLQ7vDPY SOmEkRYSkXDeuostr/LV93hpfM8JoYFUK7JPlz0J/j7IY2X+YxVElI7yevkprrX2Ys8L bGQDJjgNTmqmnIsxj9WH7TzImICKiuveJSq9ja3jGmOHZkPBAO1rVUfKIvAqMt/3UKao PZWab3tazMD1HVhe1rL6FYoW51Qsm1x0lBAqTj4ruKDaijuVXUcydFaRMxwat106eBka iZKQ== X-Gm-Message-State: AOAM532q/6+lgkI9lsoT08fLoUbx5vxwzSwirYdqSim22Y/JmWQyXPiK EIkAX7JcyhQTVkP3BozBDsid2528/WIuKOJ/8j13AA== X-Google-Smtp-Source: ABdhPJxGS7NXJM+KF1KuyYHIVqAed9DlcbOpk+BD8O26PFhlwzKyT5bWnxIP3ustua72qmFf7FMunXCN383WjCwEW5Q= X-Received: by 2002:aca:a988:: with SMTP id s130mr943053oie.172.1605210744714; Thu, 12 Nov 2020 11:52:24 -0800 (PST) MIME-Version: 1.0 References: <0a9b63bff116734ab63d99ebd09c244332d71958.1605046662.git.andreyknvl@google.com> <20201111174902.GK517454@elver.google.com> In-Reply-To: From: Marco Elver Date: Thu, 12 Nov 2020 20:52:12 +0100 Message-ID: Subject: Re: [PATCH v2 10/20] kasan: inline and rename kasan_unpoison_memory To: Andrey Konovalov Cc: Dmitry Vyukov , Alexander Potapenko , Catalin Marinas , Will Deacon , Vincenzo Frascino , Evgenii Stepanov , Andrey Ryabinin , Branislav Rankov , Kevin Brodsky , Andrew Morton , kasan-dev , Linux ARM , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" 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 Thu, 12 Nov 2020 at 20:45, Andrey Konovalov wrote: > > On Wed, Nov 11, 2020 at 6:49 PM Marco Elver wrote: > > > > On Tue, Nov 10, 2020 at 11:20PM +0100, Andrey Konovalov wrote: > > > Currently kasan_unpoison_memory() is used as both an external annotation > > > and as an internal memory poisoning helper. Rename external annotation to > > > kasan_unpoison_data() and inline the internal helper for hardware > > > tag-based mode to avoid undeeded function calls. > > > > I don't understand why this needs to be renamed again. The users of > > kasan_unpoison_memory() outweigh those of kasan_unpoison_slab(), of > > which there seems to be only 1! > > The idea is to make kasan_(un)poison_memory() functions inlinable for > internal use. It doesn't have anything to do with the number of times > they are used. > > Perhaps we can drop the kasan_ prefix for the internal implementations > though, and keep using kasan_unpoison_memory() externally. Whatever avoids changing the external interface, because it seems really pointless. I can see why it's done, but it's a side-effect of the various wrappers being added. I'd much rather prefer we do it right from the beginning, and cleaning up things very much is related to this series vs. just making things uglier and hoping somebody will clean it up later. > > So can't we just get rid of kasan_unpoison_slab() and just open-code it > > in mm/mempool.c:kasan_unpoison_element()? That function is already > > kasan-prefixed, so we can even place a small comment there (which would > > also be an improvement over current interface, since > > kasan_unpoison_slab() is not documented and its existence not quite > > justified). > > We can, but this is a change unrelated to this patch. Not quite, we're trying to optimize KASAN which is related -- this patch as-is would obviously change, but replaced by a patch simplifying things. This change as-is makes 2 changes outside of KASAN, whereas if we removed it it would only be 1 and we end up with less cruft.