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=-3.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 2FBDBC5519F for ; Thu, 12 Nov 2020 19:53:43 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A5E102078D for ; Thu, 12 Nov 2020 19:53:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kO/5dUNi"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="LyRcRhjy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5E102078D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2KGFXJgsP1AA9WuIQQKi9bCPnkmZRRxgAi8Jj+HQR/Q=; b=kO/5dUNi/OjfDb4gcPWSnCPns pqbjlq8lwzanGL09m9Yd2RffTTh+u4O/SSWo8z8G4ZjKKSJVwlcOPgehww76eezYQY6sl4Ghv21JJ 3OKITDMAn287uguNOTkdv4Tm357u7X4QOEEfk4SgkBY0YRaLmZ/QOoOeWVDt4pgKv2NRIjp1K8Xoq /t+qqLsA/yW5kUyNiITvcHXUW24mzCqdWzTozCcpOd9ss60kcF/p8kxUWBFJPPD3jQWiqnTs689w5 TUuiOm7uSTZD4K3JKYyjN04puG1wG0V/T8ywuxycMGKVsWIGD76F1WhJEek0Qf68NhRCb2JloJyaz GwptMZVhw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdIdy-0003so-Iv; Thu, 12 Nov 2020 19:52:30 +0000 Received: from mail-oi1-x243.google.com ([2607:f8b0:4864:20::243]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdIdv-0003qy-3b for linux-arm-kernel@lists.infradead.org; Thu, 12 Nov 2020 19:52:28 +0000 Received: by mail-oi1-x243.google.com with SMTP id m13so7737097oih.8 for ; Thu, 12 Nov 2020 11:52:26 -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=bA1RG+YTExJzatzWSwoobIReofgwrt9soGXWrEt/7Nk84azCnvmKQPB1fDqUALL0sF VijXn77bwPCJIhmoNujTQOK2/rBn6rXaR9LInwfUOb6k5Hr+xDp89m9WEH5I2deREDq0 2se3Q/rNgX716bwuEsaRapr5ty0qW0Xbvauo4cnhRlQ81ODVvRfTSkRIfTZPDOWnjChK NS1qUyz0zNrKRG1Ed4wOHh2lA85HzlY8cLKUqoS6EqlTp8rTyABZUKAU7LK9L+ffKXq4 XvFRvKTwMkQIQuNoxGUwpiPElxs3LwtiVmmBR8tCWJNLfIhI6kfZJnzvt1KE+5+0qIzH sZBw== X-Gm-Message-State: AOAM531AWuM9zd0zE9XU6RFD0nAXEAHwSI3Fw789JuRlIVjwKl/jFfXY QurvPUkc9B53TKcBD1YiDBYpHV09MQbxsBLmvrqP0Q== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201112_145227_247997_961E3FA5 X-CRM114-Status: GOOD ( 25.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux ARM , Branislav Rankov , Catalin Marinas , Kevin Brodsky , Will Deacon , LKML , kasan-dev , Linux Memory Management List , Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , Andrew Morton , Vincenzo Frascino , Evgenii Stepanov Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel