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 22E2DC433E2 for ; Tue, 8 Sep 2020 15:56:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A256022527 for ; Tue, 8 Sep 2020 15:56:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="wETpD6sa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A256022527 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 0F24C6B0070; Tue, 8 Sep 2020 11:56:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A2326B0071; Tue, 8 Sep 2020 11:56:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFAB3900005; Tue, 8 Sep 2020 11:56:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) by kanga.kvack.org (Postfix) with ESMTP id D97056B0070 for ; Tue, 8 Sep 2020 11:56:40 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7B74F362A for ; Tue, 8 Sep 2020 15:56:40 +0000 (UTC) X-FDA: 77240346960.25.girls90_5a076f9270d6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 183A71804E3A8 for ; Tue, 8 Sep 2020 15:56:40 +0000 (UTC) X-HE-Tag: girls90_5a076f9270d6 X-Filterd-Recvd-Size: 5866 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Sep 2020 15:56:39 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id g4so19698381wrs.5 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=c5LkZgT1QsDKZ4nv7JluHjVm7/nROdFBB0LVB48oyclsuJCDE7kVq+JKdUUOAJ/95H qGLYieA2UpObvLV4IJXi7LFSzcxzI0mrXwM/Rxuat4yLyc4r/AhwwzGsttYGy90NYZCT oB4CflCX6APxjjwZhthOqxwV8QsdEbLm6PZK+PRoUzuog6yag5rX7r+0TpvpO1FuhQTO /uC2qOIXj4Doj11Y1yQ9D7FJ2BkgQbNWN2DIMlu9gHR7uVCMu1ZyY/n9PDuCdrIxnWu3 uVGpzonAcFRpcqCIRNxilLFZUjACFQVKEk/vR5njZoyLzx87aAw9b9F0p0PzP9RDRVSx 0qGA== X-Gm-Message-State: AOAM532GBZuZPqq6GTGKJAPwmhLJp0j0KHg6DJkkCIJhwM2dc19nlLyr cwr5T1+XgkP64Ty8vmj+wNv00w== 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) X-Rspamd-Queue-Id: 183A71804E3A8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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, 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