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 811DCC433DB for ; Tue, 12 Jan 2021 22:55:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3D49023122 for ; Tue, 12 Jan 2021 22:55:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394900AbhALWzh (ORCPT ); Tue, 12 Jan 2021 17:55:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2394889AbhALWzg (ORCPT ); Tue, 12 Jan 2021 17:55:36 -0500 Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82067C061575 for ; Tue, 12 Jan 2021 14:54:55 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id o11so105526ote.4 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=Umpv6A0HVxt4vavOZanjeRmIojCvg6PYBteZDWQd+72IbSx9g9c+Ws+/pfgsj0mPQc xoV0Yekh2Zi0XvZvJNZrld7/y93JCki7qGyggkvJYFneP/To/8rtNNTNzR137NFZ9SAj f1GC/ztPTORlB8RrBd5+kdYchoKhNZQuGagYttptInaBQJqJ1t9jWG81+DunNJ6WztEf hIfp0uZGQTqCgLNi6GZBr99clMTW+sCQ8siSvuqKwP40VHgfFqHSH4jGPcYKq1I6VcOV ap1uyOn7UnV8tBI35MoqS61EouO7EPIoDYV2YcQapBjpDcQMk5DIYIpQUfHOAMGAFnuc N2Ig== X-Gm-Message-State: AOAM533bKedNXWbbHVVv1MtStT73xXLNsG7gkAtM1BYcfc83vZd1vdXA /ujyv43zaKevnMdOW21NMxdyE/ul8E+W9WKCvXu8Rw== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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=-4.0 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 B95C5C433DB for ; Tue, 12 Jan 2021 22:56:49 +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 646DC2311F for ; Tue, 12 Jan 2021 22:56:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 646DC2311F 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=l9f2pi0AnYfVfk2xgc4hN+5ypFMwvpQXfFLYJZFhHmM=; b=0F4XHCq8Rw3n4rBbXabSnDSM0 DTP5yAT8+eOcmelybmkSJE5TT04Ox4NxuJcHmTYxzcr7uJQ23sfrirzkJOUua/SMKgvb3RKeltIVo 01DrL1jGNc1JRKKNw81yiCzWhod0G/kQWo+FPU54dSEV/dh+orWC1RWkjxw09i57o1mBkXUpTWn+H OmkFrADAgirP32yayQXzdMaOprk2UH7WG8aQP8q/oeW0ZRJRA9g/ia9l0VyfVz4viiND46w106jnh CX7lOQ7n5PnCBnuHQliNWa+mX4B4S2dDFojVp71U/3p7Zlx02UBVBYU7j/przmmOtkrXpwp9YTw98 vMV9GdVuQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kzSZ5-000742-H9; Tue, 12 Jan 2021 22:55:03 +0000 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kzSZ0-00071c-No for linux-arm-kernel@lists.infradead.org; Tue, 12 Jan 2021 22:54:59 +0000 Received: by mail-ot1-x32d.google.com with SMTP id j20so100518otq.5 for ; Tue, 12 Jan 2021 14:54:56 -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=OxQriJKJzK4fruqYXZTopK+imppxIvEdysBa+ad4wjlbGAX53OZ6R73nU9RZhSTRK7 x8+IImXcgOdI5ZCgIAuoUis3AUYw9JkLMVDG8iI+UhOSmDu8PTw8eIy2e4u2zIAPIjVf m+8P6svA1DJdHOB6TrMvX0WN7Vq9fXPULVoymCVTVZITfyIV0PkqOgyujPpACDV9miQC Rp+RN6ScmZImnOhR+bSg6kD9cdq/383szCl1Q0+jePb14b9+wAPmX/qUj763Vl0qL93V VJPNmW16vSziKPqtmz9z7Haz3yTZF1qtTry/U1wwWRIR+1nmzCAAx582VyTXlSp43P/M Q0KQ== X-Gm-Message-State: AOAM532iDo4bkRpGgZedlaOP+J9nWfwn8UR+/qMc4dBzbkQKsUoxqXDi fEWr2foWMLkkZNHGhSNX1IL99hB5DnNbgJpxmjN//A== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210112_175458_867759_71B56031 X-CRM114-Status: GOOD ( 28.69 ) 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 , Evgenii Stepanov , Andrey Ryabinin , Andrew Morton , Vincenzo Frascino , Dmitry Vyukov 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel