Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1321959rwi; Thu, 27 Oct 2022 14:18:54 -0700 (PDT) X-Google-Smtp-Source: AMsMyM53/wNiIuiV1yBkAMuOW6m5Yz1U8y0hEseaoqh/gKfsp2GKYeDZ4gNmY6ajpRWudXu+0OKg X-Received: by 2002:a05:6402:4282:b0:459:befa:c79c with SMTP id g2-20020a056402428200b00459befac79cmr48537408edc.23.1666905533994; Thu, 27 Oct 2022 14:18:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666905533; cv=none; d=google.com; s=arc-20160816; b=FOcp98zeOneyR2kYyxJm1hrl1pUXNIG8Yu+lV7kpbYqdrd1x4VbaFP2zPZ6AFJ7O81 XxSCJr6Bj/w8nwrpCi73waqr7MsapqLpp81w5Wi40SQwRqPiwKzNsNesUtM3+Qr7JZCO 0U53oLNiym0asF7QtyDr5vPbf5LoeDnZ2/KCzL+ZX2jxrW0886gq4RO+Sf5AUFX/E7Xi AbjD+21CbHGU7VH/Nhw0IuqKKm/KhdN/OkixjfesQf3NlnxqUwTUkUXMIyuNWosHhBwJ Pq672M4p3AC8WJjla2SeYmRGAVrrJuMBZQRXp3PBbB4dv2/hvWSnQtjEAOmf/UgymauA J0ZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=eX5iswCEFEjamv9gIuEx12HIvGG8RCEeLnd91qn6Njc=; b=gslWjM7cl+h/AAVV0gBP+EGijknGWxxj6DNyNrxaarVt2LfjphT9TYapj6UNuFvkE0 tofB1bL5HWNnjLMaXm4QHcSXyRAgjuclttE/yjWpMC61qNFCXrwTf4Teoyw2ShWCFo6w /G5k2I4ZaNj/3iY9MOSqMmZZLVc7xeEmRDPsiw9XBBfOwyJZt8BU9OeZ6xkYZGWbUsRU 2BxpJ9mSXQdraA4grSOcIPrXyEu9dvehyG/8fknbFtDtRGZVfegyg6LqPKO8U4OrfzjL t/4Hdy5B03GPgcuQ0rE6A27KyHFd3+XmbvQMGaDmejKpEKbLmgNsEe4KvLdToztrPl0p FJFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=cwgeAse8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v19-20020aa7d653000000b00459ff7667b4si2296809edr.203.2022.10.27.14.18.28; Thu, 27 Oct 2022 14:18:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=cwgeAse8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237185AbiJ0Uwf (ORCPT + 99 others); Thu, 27 Oct 2022 16:52:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236658AbiJ0Uvx (ORCPT ); Thu, 27 Oct 2022 16:51:53 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C5B261137 for ; Thu, 27 Oct 2022 13:45:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 90F0F624E0 for ; Thu, 27 Oct 2022 20:44:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0051BC4FF0A; Thu, 27 Oct 2022 20:44:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1666903475; bh=eSie5cxyhFgYqzyXxlt/yaovtCT91qgoQ7QxhgbrCRA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cwgeAse8AScdR/vozj93GckLyLgrV217HBziNU9X3Uavagf8OmVJvdNpRYjIR979v fnLJGoonLANrwPU4fEb5qkH+t/YUNePk9kk0Z+X/FEgOhzr4fbbu1L+fqXjQeaSdjX ZbcDFIrWNEbpTq+AJVXaMoT+xObDtj+dad+lE5BI= Date: Thu, 27 Oct 2022 13:44:33 -0700 From: Andrew Morton To: andrey.konovalov@linux.dev Cc: Marco Elver , Andrey Konovalov , Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , kasan-dev@googlegroups.com, Peter Collingbourne , Evgenii Stepanov , Florian Mayer , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Subject: Re: [PATCH] kasan: allow sampling page_alloc allocations for HW_TAGS Message-Id: <20221027134433.61c0d75246cc68455ea6dfd2@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Oct 2022 22:10:09 +0200 andrey.konovalov@linux.dev wrote: > From: Andrey Konovalov > > Add a new boot parameter called kasan.page_alloc.sample, which makes > Hardware Tag-Based KASAN tag only every Nth page_alloc allocation. > > As Hardware Tag-Based KASAN is intended to be used in production, its > performance impact is crucial. As page_alloc allocations tend to be big, > tagging and checking all such allocations introduces a significant > slowdown in some testing scenarios. The new flag allows to alleviate > that slowdown. > > Enabling page_alloc sampling has a downside: KASAN will miss bad accesses > to a page_alloc allocation that has not been tagged. > The Documentation: > --- a/Documentation/dev-tools/kasan.rst > +++ b/Documentation/dev-tools/kasan.rst > @@ -140,6 +140,10 @@ disabling KASAN altogether or controlling its features: > - ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc > allocations (default: ``on``). > > +- ``kasan.page_alloc.sample=`` makes KASAN tag only > + every Nth page_alloc allocation, where N is the value of the parameter > + (default: ``1``). > + explains what this does but not why it does it. Let's tell people that this is here to mitigate the performance overhead. And how is this performance impact observed? The kernel just gets overall slower? If someone gets a KASAN report using this mitigation, should their next step be to set kasan.page_alloc.sample back to 1 and rerun, in order to get a more accurate report before reporting it upstream? I'm thinking "no"? Finally, it would be helpful if the changelog were to give us some sense of the magnitude of the impact with kasan.page_alloc.sample=1. Does the kernel get 3x slower? 50x?