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=-12.9 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_AGENT_SANE_1, 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 1017AC433E2 for ; Tue, 8 Sep 2020 16:08:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9E724206E7 for ; Tue, 8 Sep 2020 16:08:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="wETpD6sa" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731318AbgIHQIe (ORCPT ); Tue, 8 Sep 2020 12:08:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731039AbgIHQAE (ORCPT ); Tue, 8 Sep 2020 12:00:04 -0400 Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF0D0C06179B for ; Tue, 8 Sep 2020 08:56:39 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id o5so19638766wrn.13 for ; Tue, 08 Sep 2020 08:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jYC9v1Z1TC/eRVDb6B6iUcOvbi2c078flAMPYhklKtQ=; b=wETpD6saEAEz/nnn8zVtwhh+gaFPha+TeS89jJ1i0WXRSxkwSLmbkgYLe8LJONzyMS DoB7HEnSel284io7HecToViYhGiJ/osVBiEYD5yf36sYhXeLWHEvuky/VfFW+7XxkgGB VNk4oD+jr9cpDC8j7R2bk16HED+JGEVY/OcjOdN2e+kZrHY2LHNqjx+alq560KySCd1/ RwuqL+2rbOxyAm0vQxuu+ygoqRDiR/sxu6RsaVECGbE7ZTmzbo3vAPc3y+pfvc+FtQcc g1bQM/CkUw5uoAWK6aYaUslAe00EShXz22vICKweKwyYvAPpqK2uKAcCW+a4z8jnwfTk tehQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jYC9v1Z1TC/eRVDb6B6iUcOvbi2c078flAMPYhklKtQ=; b=aPPGpkPbgaj118C1mWjkjZM082+NknRP4OWJnU/eyYvKQaMV4GJ481xS8bJ2KfXHZY KPXQw6iXtSK/WOQs2/+KaOyPE7ybEsKh0Sm7Yddg2QXzp7gsox8TbVgcAS7oA65gpLs5 I3s4kuQlKFF3aFoL+CG/3bywIaRyIlH9wpv3WVFtceSz5ofJAytuxIE7gjkegtR9pQrE 7cc3wopxWCUOhwH3aLEM2yKC0X7MIJoRA0gtZQUQ0sZsbZvIOEjzNMw2C+5JLvh/NquS +Em6KQmxWOrHQn1H/+uFiutk7q1t08lLC1RoEHscznhsbLKr3VH6MwexwG27HLygfjVA e5rw== X-Gm-Message-State: AOAM532sXaXA05KZEeL3PabCKGvZ93hG9xw3527V12HuqUUnZyfI4Mi9 Xg2JajqcCObhwVMuGXwleMz9UA== X-Google-Smtp-Source: ABdhPJzbyBGQJjklA0DbEeiaRcvxaMdt7wtqKlePMw2vv0wGDtTenivAuH+P4XF9OnbAiMxdsAAPtw== X-Received: by 2002:a5d:4a4b:: with SMTP id v11mr335425wrs.36.1599580598237; Tue, 08 Sep 2020 08:56:38 -0700 (PDT) Received: from elver.google.com ([100.105.32.75]) by smtp.gmail.com with ESMTPSA id h184sm34756040wmh.41.2020.09.08.08.56.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 08:56:37 -0700 (PDT) Date: Tue, 8 Sep 2020 17:56:31 +0200 From: Marco Elver To: Vlastimil Babka Cc: Dave Hansen , glider@google.com, akpm@linux-foundation.org, catalin.marinas@arm.com, cl@linux.com, rientjes@google.com, iamjoonsoo.kim@lge.com, mark.rutland@arm.com, penberg@kernel.org, hpa@zytor.com, paulmck@kernel.org, andreyknvl@google.com, aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, dvyukov@google.com, edumazet@google.com, gregkh@linuxfoundation.org, mingo@redhat.com, jannh@google.com, corbet@lwn.net, keescook@chromium.org, peterz@infradead.org, cai@lca.pw, tglx@linutronix.de, will@kernel.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Message-ID: <20200908155631.GC61807@elver.google.com> References: <20200907134055.2878499-1-elver@google.com> <20200908153102.GB61807@elver.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.14.4 (2020-06-18) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 08, 2020 at 05:36PM +0200, Vlastimil Babka wrote: > On 9/8/20 5:31 PM, Marco Elver wrote: > >> > >> How much memory overhead does this end up having? I know it depends on > >> the object size and so forth. But, could you give some real-world > >> examples of memory consumption? Also, what's the worst case? Say I > >> have a ton of worst-case-sized (32b) slab objects. Will I notice? > > > > KFENCE objects are limited (default 255). If we exhaust KFENCE's memory > > pool, no more KFENCE allocations will occur. > > Documentation/dev-tools/kfence.rst gives a formula to calculate the > > KFENCE pool size: > > > > The total memory dedicated to the KFENCE memory pool can be computed as:: > > > > ( #objects + 1 ) * 2 * PAGE_SIZE > > > > Using the default config, and assuming a page size of 4 KiB, results in > > dedicating 2 MiB to the KFENCE memory pool. > > > > Does that clarify this point? Or anything else that could help clarify > > this? > > Hmm did you observe that with this limit, a long-running system would eventually > converge to KFENCE memory pool being filled with long-aged objects, so there > would be no space to sample new ones? Sure, that's a possibility. But remember that we're not trying to deterministically detect bugs on 1 system (if you wanted that, you should use KASAN), but a fleet of machines! The non-determinism of which allocations will end up in KFENCE, will ensure we won't end up with a fleet of machines of identical allocations. That's exactly what we're after. Even if we eventually exhaust the pool, you'll still detect bugs if there are any. If you are overly worried, either the sample interval or number of available objects needs to be tweaked to be larger. The default of 255 is quite conservative, and even using something larger on a modern system is hardly noticeable. Choosing a sample interval & number of objects should also factor in how many machines you plan to deploy this on. Monitoring /sys/kernel/debug/kfence/stats can help you here. 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=-5.2 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,USER_AGENT_SANE_1 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 79409C43461 for ; Tue, 8 Sep 2020 16:31:14 +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 028E6206B8 for ; Tue, 8 Sep 2020 16:31:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hKo49Csl"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="wETpD6sa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 028E6206B8 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bz7r1BMJe4u2RcQfXHp/LZMPkkiVpUtcY/lA7plv7vc=; b=hKo49CslnC16oYbM4FgEF+O0v /1Uw+vMMadrkw2SE2BvVuQ9VynK7kk4VXUZmvFr3mYb7yIJ36yvf8m5Nrsfqh2TfQa/NolPkxwkli Rms9+67UYQMd3OY4/nqoOPd3kUCgUtFIK0PfzF38qaFByIiIIqWkb9neXDmyV1Zsp6Fq15+hogt8p x1XTG5NkEL95E4T2yM9xw7V9+PmmAw2dV0XPm/n4YGkSOzgHiF/gEg8tXi54X6zdPFCfT/zLsoKfp XemfELeF2DiW6f8qG4Q4vVPkmo9Wa71+qn2/3wX+JQpkLLvOUmIaz2TlKoJeB15nwAvMVlkitxORc epQiLGA0w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFfz8-0000gB-0I; Tue, 08 Sep 2020 15:56:42 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFfz5-0000fE-EO for linux-arm-kernel@lists.infradead.org; Tue, 08 Sep 2020 15:56:40 +0000 Received: by mail-wr1-x443.google.com with SMTP id k15so19641989wrn.10 for ; Tue, 08 Sep 2020 08:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jYC9v1Z1TC/eRVDb6B6iUcOvbi2c078flAMPYhklKtQ=; b=wETpD6saEAEz/nnn8zVtwhh+gaFPha+TeS89jJ1i0WXRSxkwSLmbkgYLe8LJONzyMS DoB7HEnSel284io7HecToViYhGiJ/osVBiEYD5yf36sYhXeLWHEvuky/VfFW+7XxkgGB VNk4oD+jr9cpDC8j7R2bk16HED+JGEVY/OcjOdN2e+kZrHY2LHNqjx+alq560KySCd1/ RwuqL+2rbOxyAm0vQxuu+ygoqRDiR/sxu6RsaVECGbE7ZTmzbo3vAPc3y+pfvc+FtQcc g1bQM/CkUw5uoAWK6aYaUslAe00EShXz22vICKweKwyYvAPpqK2uKAcCW+a4z8jnwfTk tehQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jYC9v1Z1TC/eRVDb6B6iUcOvbi2c078flAMPYhklKtQ=; b=gJcwMX6xUi/2Q2dB3mRHl7Ukxl4Tqxntp9sUIHGqg/nQQJdppuOBgyRMJ63ONIiB/H CyOSDdmA+lTqLgyI32zHgV7Cah1rTADKyBERsP4Cjb/FwGvZZlSCmhUY2i/ZfivPHN3Y P96/1Tz6jCJ9IKPfNVRP1TmLH+Y3PL5vINLJP9ZFQXmRMFNOd7yeUNSqKp8GPe1Lf2Ho 8ez0wz2gNo+sg0Vc2HH9oekbWS7MlBx5HvRfpd5BqBHnz3J5srz7GhtbQaM9xW/48cJz WtuKnczqohls1Ptb8xNB38/gNYA54wlW5h4okHysdZX/KN/7lTQADWvY2duW963GU5rQ jMag== X-Gm-Message-State: AOAM5302B7UroayZ6co3EyVN0M4Q/BvlqVe6jyTUIIiLDzijKTS0f73b lck1GnG62SqlrVVKVBiLWBfyzA== X-Google-Smtp-Source: ABdhPJzbyBGQJjklA0DbEeiaRcvxaMdt7wtqKlePMw2vv0wGDtTenivAuH+P4XF9OnbAiMxdsAAPtw== X-Received: by 2002:a5d:4a4b:: with SMTP id v11mr335425wrs.36.1599580598237; Tue, 08 Sep 2020 08:56:38 -0700 (PDT) Received: from elver.google.com ([100.105.32.75]) by smtp.gmail.com with ESMTPSA id h184sm34756040wmh.41.2020.09.08.08.56.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 08:56:37 -0700 (PDT) Date: Tue, 8 Sep 2020 17:56:31 +0200 From: Marco Elver To: Vlastimil Babka Subject: Re: [PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Message-ID: <20200908155631.GC61807@elver.google.com> References: <20200907134055.2878499-1-elver@google.com> <20200908153102.GB61807@elver.google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.14.4 (2020-06-18) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200908_115639_511878_1D7B7254 X-CRM114-Status: GOOD ( 19.74 ) 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: mark.rutland@arm.com, linux-doc@vger.kernel.org, peterz@infradead.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, Dave Hansen , edumazet@google.com, glider@google.com, hpa@zytor.com, cl@linux.com, will@kernel.org, corbet@lwn.net, x86@kernel.org, kasan-dev@googlegroups.com, mingo@redhat.com, linux-arm-kernel@lists.infradead.org, rientjes@google.com, aryabinin@virtuozzo.com, keescook@chromium.org, paulmck@kernel.org, jannh@google.com, andreyknvl@google.com, bp@alien8.de, luto@kernel.org, tglx@linutronix.de, akpm@linux-foundation.org, dvyukov@google.com, linux-mm@kvack.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, penberg@kernel.org, cai@lca.pw, iamjoonsoo.kim@lge.com 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, Sep 08, 2020 at 05:36PM +0200, Vlastimil Babka wrote: > On 9/8/20 5:31 PM, Marco Elver wrote: > >> > >> How much memory overhead does this end up having? I know it depends on > >> the object size and so forth. But, could you give some real-world > >> examples of memory consumption? Also, what's the worst case? Say I > >> have a ton of worst-case-sized (32b) slab objects. Will I notice? > > > > KFENCE objects are limited (default 255). If we exhaust KFENCE's memory > > pool, no more KFENCE allocations will occur. > > Documentation/dev-tools/kfence.rst gives a formula to calculate the > > KFENCE pool size: > > > > The total memory dedicated to the KFENCE memory pool can be computed as:: > > > > ( #objects + 1 ) * 2 * PAGE_SIZE > > > > Using the default config, and assuming a page size of 4 KiB, results in > > dedicating 2 MiB to the KFENCE memory pool. > > > > Does that clarify this point? Or anything else that could help clarify > > this? > > Hmm did you observe that with this limit, a long-running system would eventually > converge to KFENCE memory pool being filled with long-aged objects, so there > would be no space to sample new ones? Sure, that's a possibility. But remember that we're not trying to deterministically detect bugs on 1 system (if you wanted that, you should use KASAN), but a fleet of machines! The non-determinism of which allocations will end up in KFENCE, will ensure we won't end up with a fleet of machines of identical allocations. That's exactly what we're after. Even if we eventually exhaust the pool, you'll still detect bugs if there are any. If you are overly worried, either the sample interval or number of available objects needs to be tweaked to be larger. The default of 255 is quite conservative, and even using something larger on a modern system is hardly noticeable. Choosing a sample interval & number of objects should also factor in how many machines you plan to deploy this on. Monitoring /sys/kernel/debug/kfence/stats can help you here. Thanks, -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel