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=-13.3 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 0937DC433DB for ; Tue, 12 Jan 2021 22:54:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6C7C723122 for ; Tue, 12 Jan 2021 22:54:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6C7C723122 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 870D16B0107; Tue, 12 Jan 2021 17:54:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 821626B0108; Tue, 12 Jan 2021 17:54:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 736EB6B0109; Tue, 12 Jan 2021 17:54:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id 5D6DB6B0107 for ; Tue, 12 Jan 2021 17:54:56 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 273D23630 for ; Tue, 12 Jan 2021 22:54:56 +0000 (UTC) X-FDA: 77698629792.17.boats51_5d0f48327519 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 0DDB6180D0185 for ; Tue, 12 Jan 2021 22:54:56 +0000 (UTC) X-HE-Tag: boats51_5d0f48327519 X-Filterd-Recvd-Size: 5811 Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 22:54:55 +0000 (UTC) Received: by mail-ot1-f54.google.com with SMTP id x5so80113otp.9 for ; Tue, 12 Jan 2021 14:54:55 -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=/vYKtRUvIW2ynJjXb8EKOHINwCaI0vhIQWTSSZNFGWc=; b=Ww3KXfMqu1sID+h6joR8rNOtxPU4PNA7tn8XQ8NBQKSBnKwNcJ6+X9lq3PpgN+hH5C eAVVZ27v93yjtmKeKXFIUb5YpFgwY2sQVx6nMZ/K/nz+d7jZgnft0bnPIKAo07hmdX7J qbHJVc9RSX4qi+51lMX4wjcktwZk7Yk/hAGcsbs/yRKDvMJfFPaI4/DqV2cu84/SRYFA shVTnQRqHvqvXPEQuPPvZNWU8mD2p+mplAQHF/36TQLzIcLVCbvzbD2rhirHROBQ9T/l kGt5XvlCgeXjbrLIOMyKiG9+XIqT8r+iT+JwiyfHZq12hQBLJTa/QDWoUy8F1abiwCD4 hZAQ== 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=/vYKtRUvIW2ynJjXb8EKOHINwCaI0vhIQWTSSZNFGWc=; b=aXldJByMkM2BsYoa4gnkUGh88qe1GBORLM3itUE4Esk6ycEkmZbtgykJETgy0N5lyW MwrvmcbTgJBoxBqq5k8yq4JqcqD9sBi9C8X8GvR38HmSbfV6Nmt9b6QiT+epUL0gB3QS HhbGQzo39QHoUW5gtdw5jOm0lN+PM6sLZN9wfihl4okUxLRal5I6ePYXbJUTtMOVFoLW DRRnVYue99EXdlaP/d6nhOQMjmdJ/0NuVgT+1qRBtLFAplY2ch7Dc9Xt1e2S1NLV1XM5 3TC/b/zTzf8NJt+79EhckiHGuIDvv9xKNjl8fU5xUh4CSPeio4sNJ/c/x8CyPP04dxuu Hbhg== X-Gm-Message-State: AOAM530UbvMLJv2nIHTq//EHxp1jnDYflFmBrwak20dDxbuWv7Fl+DXC eqK7OdlRi1StDfBhGTPx0wfdSQ8rs2NnRDqs+FYHuA== X-Google-Smtp-Source: ABdhPJzwgdUScBJYneAEXMBmswPtj1jt0k0m1Q8bFyR9znqR0OjkiLU8szsYkKQ3VBpF3LCBnWH9up1VjI4lQJISCQ8= X-Received: by 2002:a05:6830:19ca:: with SMTP id p10mr1108587otp.233.1610492094692; Tue, 12 Jan 2021 14:54:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Tue, 12 Jan 2021 23:54:43 +0100 Message-ID: Subject: Re: [PATCH 10/11] kasan: fix bug detection via ksize for HW_TAGS mode To: Andrey Konovalov Cc: Catalin Marinas , Vincenzo Frascino , Dmitry Vyukov , Alexander Potapenko , Andrew Morton , Will Deacon , Andrey Ryabinin , Evgenii Stepanov , Branislav Rankov , Kevin Brodsky , 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 Tue, 12 Jan 2021 at 22:16, Andrey Konovalov wrote: > > On Tue, Jan 12, 2021 at 3:32 PM Marco Elver wrote: > > > > > +/* > > > + * Unlike kasan_check_read/write(), kasan_check_byte() is performed even for > > > + * the hardware tag-based mode that doesn't rely on compiler instrumentation. > > > + */ > > > > We have too many check-functions, and the name needs to be more precise. > > Intuitively, I would have thought this should have access-type, i.e. > > read or write, effectively mirroring a normal access. > > > > Would kasan_check_byte_read() be better (and just not have a 'write' > > variant because we do not need it)? This would restore ksize() closest > > to what it was before (assuming reporting behaviour is fixed, too). > > > > void kasan_poison(const void *address, size_t size, u8 value); > > > void kasan_unpoison(const void *address, size_t size); > > > -bool kasan_check_invalid_free(void *addr); > > > +bool kasan_check(const void *addr); > > > > Definitely prefer shorted names, but we're in the unfortunate situation > > of having numerous kasan_check-functions, so we probably need to be more > > precise. > > > > kasan_check() makes me think this also does reporting, but it does not > > (it seems to only check the metadata for validity). > > > > The internal function could therefore be kasan_check_allocated() (it's > > now the inverse of kasan_check_invalid_free()). > > Re: kasan_check_byte(): > > I think the _read suffix is only making the name longer. ksize() isn't > checking that the memory is readable (or writable), it's checking that > it's addressable. At least that's the intention of the annotation, so > it makes sense to name it correspondingly despite the implementation. > > Having all kasan_check_*() functions both checking and reporting makes > sense, so let's keep the kasan_check_ prefix. > > What isn't obvious from the name is that this function is present for > every kasan mode. Maybe kasan_check_byte_always()? Although it also > seems too long. > > But I'm OK with keeping kasan_check_byte(). This is fine. > Re kasan_check(): > > Here we can use Andrew's suggestion about the name being related to > what the function returns. And also drop the kasan_check_ prefix as > this function only does the checking. > > Let's use kasan_byte_accessible() instead of kasan_check(). Sounds reasonable to me. Thanks, -- Marco