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 59D17C5519F for ; Thu, 12 Nov 2020 22:20:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 91DEB22227 for ; Thu, 12 Nov 2020 22:20:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dFN+5nhP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 91DEB22227 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 EA5F06B005C; Thu, 12 Nov 2020 17:20:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E55CC6B005D; Thu, 12 Nov 2020 17:20:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1E1B6B0068; Thu, 12 Nov 2020 17:20:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0144.hostedemail.com [216.40.44.144]) by kanga.kvack.org (Postfix) with ESMTP id 9AEA36B005C for ; Thu, 12 Nov 2020 17:20:40 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 467C4180AD802 for ; Thu, 12 Nov 2020 22:20:40 +0000 (UTC) X-FDA: 77477186640.20.grape02_4f0237e27309 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 271E3180C07A3 for ; Thu, 12 Nov 2020 22:20:40 +0000 (UTC) X-HE-Tag: grape02_4f0237e27309 X-Filterd-Recvd-Size: 5980 Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Thu, 12 Nov 2020 22:20:39 +0000 (UTC) Received: by mail-ot1-f67.google.com with SMTP id h16so3063406otq.9 for ; Thu, 12 Nov 2020 14:20:39 -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=qTAA2mjTH1s5gJvXfoqFOnb2RIhffz7/HPf/PMilg1s=; b=dFN+5nhP2JgNsIO+pN31g3PQMctzBg5Wp/ncFqisaXZKXLFc1gjnImkp1mqP4HzxON /6vtZoMbWfQBequoH+jOBoXPCJkahX7hmHKD5aCZNUSIVyUWnm1HzYhnxssg0THcn2kl YI8ecBu65VO7pscM9wkv1zVNMwoUkGC9rPEY9TUXiOsvH/YC+GwQxEqve3H00ZgdThWH DGILd7UgTmn2cTjSHq8lqRpZyINt3ffKMXVqA56W5EYUV3K8Y1wULP94qqdAM2dO9wm8 sw5W0GmZTrRf1vtd82BIDHftPFaLSvE7gAsG4aEJSHcR+dvf1FcfCHOUeT7xh7t3X2F6 ZrFQ== 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=qTAA2mjTH1s5gJvXfoqFOnb2RIhffz7/HPf/PMilg1s=; b=TkJRnsbF2NL8pz/Cm55TWQfFi2SL4o5A/1ydNFFdUYT/L4qajl0AUH4bcNvqWlLQrS XyVNRLwCPY1HBq6bUXK0mU6BzqImAlHTS1fXLHYLv+Bro3llMmTjDtSfcfSJsgVS93qr fauE2ILoPSbWjikQ5QaEwTSQ5Cx49aDAa5lN5j6DgdOTuHjwjD12vTIm1Q1hjo6+oEqm KtJXmhvlgQzJIiiMSDD2yai3mKCRmurRgp27i45zG6l2kTN0nQn+57Z8MyFoU1+ciLtj gwXQBolBbrfO5Crwz1yvyTrRKtDBYyOFwlcVeEc6ifmn8AMWVxMfomK55VgC833ty/Ck OS4w== X-Gm-Message-State: AOAM532Xs8yOL1Ey4DhDvgdwGv7bPaw99U11eHi3xOcYtjJ1/HcCKjsn A1qjjC+Jp/G1GBsH8nsAWqnSB/BWeRDss+78SMq+yw== X-Google-Smtp-Source: ABdhPJyMi4CuFKcE9FueG6D29GwD/cp6+XfVewyzA+L+8OXF8guN8DtLpuh/GzPAxMez1YVU5QiGgBLiUbCvu5CTvns= X-Received: by 2002:a9d:649:: with SMTP id 67mr1045852otn.233.1605219638578; Thu, 12 Nov 2020 14:20:38 -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 23:20:27 +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 21:54, Andrey Konovalov wrote: > > On Thu, Nov 12, 2020 at 8:52 PM Marco Elver wrote: > > > > 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. > > It looks like unposion_memory() is already taken. Any suggestions for > internal KASAN poisoning function names? I still don't like that one of these functions just forwards to the other, but we could use it to also give the external function a more descriptive name. I propose 2 options: 1. Name the internal helpers *poison_range(). 2. Name the external function kasan_unpoison_range() instead of kasan_unpoison_data(). Anything "memory" (or "data") in the allocators might not be too helpful w.r.t. descriptive function names (i.e. stripping "memory" from function names won't lessen descriptiveness given our context). Perhaps kasan_poison_range() for the external function might in fact improve the external interface (without looking at its arguments). If we need to keep the internal helpers, I'd probably go so far as to suggest renaming them to simply kasan_{poison,unpoison}(), and then building the external kasan_{poison,unpoison}_foo() on top. But maybe that's too much for now if it doesn't fit here. :-) Thanks, -- Marco