Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2609427pxb; Tue, 21 Sep 2021 03:53:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxorgHjrmUO/2l8F+3kCemzkBMfOHMnHXe8U/gbKZmRX3vBLXxJu7zdO8tfxDvUbZHl41z4 X-Received: by 2002:a02:c9d9:: with SMTP id c25mr6942944jap.81.1632221586809; Tue, 21 Sep 2021 03:53:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632221586; cv=none; d=google.com; s=arc-20160816; b=ePbv1zYST8F2dCtwaw6VIsTPKU11VKP9fY//TdrzZCswREpBhEv04HZiRYCyJu2l3k NcqWTIey3V9m3zixzjwqbolMh9uesUI/J/JwNPoSSOOrzQYiEkFl3EpUWZG4PzSrB5T9 nRjqaRjaMMkDNOOnhEvQE3GMbS3Bsi7AWKAhPHFwABB9CLinHUzdga3NSpxiDm8+tp99 MFnpFS57gpc281qyxVkHhaG0DYQt1ZNFSVw0cxz5Gzr7FPJAoi9wEXiolAzW36z1H6Ql hI1TxSHVRTf3zsavSNfkvmU6jb32mGzOjuk73JrcW1z0Am4QL6a5ohK1DVPOKp11rMni l00Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=N8im2OS98fNlJW2Ij6zQsDpm5TLK4cuMawMCjuGiTZU=; b=JqzDmqWb5qfqNCn01gdQmbzkN2wBmVSHedMVhu2BMwwR7y0pQyyioilk13I/UKZ1f1 72j3HV7/5FZ84sxvbOLmXV8Xpg+jVRT2KsYUfmbdyu8ilWcmIWx4Jlxr9EyJSsxAWZKF 47dt4bc2ghf4cJ3NmMMspgAVkAXub3Z3SX4gY2B3zrtb6WHvN2m1BbozsDxIwuiX1Jow 5TUGPOfgsbx/axOIz3/4oyuhAksdey5juGN/XGzy2t6afSScc4kL+IHESkB9/S1T8i5E hbxM77S8srOwRjwL0TVq1wQCyOX5t0s4IV9P/g7gs/sgI1d+/81MAuZLWejx43l8aef9 ilmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=RR3cWHZ7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j15si14746591jac.8.2021.09.21.03.52.55; Tue, 21 Sep 2021 03:53:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=RR3cWHZ7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232019AbhIUKxC (ORCPT + 99 others); Tue, 21 Sep 2021 06:53:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231799AbhIUKxB (ORCPT ); Tue, 21 Sep 2021 06:53:01 -0400 Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F0FAC061574 for ; Tue, 21 Sep 2021 03:51:33 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id w206so17453730oiw.4 for ; Tue, 21 Sep 2021 03:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N8im2OS98fNlJW2Ij6zQsDpm5TLK4cuMawMCjuGiTZU=; b=RR3cWHZ7Pw8yzusQe/R4SgSdvdSokVrUN1ScMzm8Low2Rp9NdUT/hMEzxFMF2nyhoD MZzrjwBiFKM9KDWtQ2ca6aNVcuzWC3B+Div+rkPUelnOGhf6sF2ltiY1VS1YQkCAY/O6 7hAzDV9UBpTMR3HWey0UrUsOsvWpsP8hyQ3FmznVziVH9+4hLqPwKxZMHHQu+80rQn0R eMjzGCNby8+kvvir55KtM/RdBpgwdVycCcPLQfxb8u8T7gI1n3cc81239/YY8lWDSZlk dAkiGsYiBTgKVF/XSqcKaI7ON9208ReerBrU6IZ4Qsb0G6Lepw7yaX/GFs6noreOq8ym +1wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N8im2OS98fNlJW2Ij6zQsDpm5TLK4cuMawMCjuGiTZU=; b=0axVG3V5hYi7IcPM/YXzrvFIdEJXKRffmRMfcDgZkDH/xS8k/nbr+WgYkGxPx23Y1Y yVL0aXbS6VLnfrwqVKj57Xmy2OL/48tIU+4QhawRZuyBTqXcYHejRFUcmEaz8J6/Cbn3 rzaUHaKsc1F8GJqvP/kFBcDIsF+lqAmohsBANw2JQnuWunXzQWJr1YoFQHUBEZtt6NBb SnqxkodL91ldKCWjWa+YnrUshTvuGPk5KHeKA52F0t0rBabeTw34m8cI0feV3ES9UnnN D5tuSNcQTqEJaqV908kcA31OAsiX2JM4QoP51id+/UqtgGPEhVkGuBLJHTn0kBlTCL9Q OCOA== X-Gm-Message-State: AOAM530bxsr1zsNTBALcxpZct+XunyI1JS/VsB9kVYBIt5DpuhuGHIic NJo8yrifeVKFz5lzHscXMGYzcWyU+1RC8oo2aO5EGw== X-Received: by 2002:aca:3083:: with SMTP id w125mr3028189oiw.109.1632221492218; Tue, 21 Sep 2021 03:51:32 -0700 (PDT) MIME-Version: 1.0 References: <20210921101014.1938382-1-elver@google.com> <20210921101014.1938382-5-elver@google.com> In-Reply-To: <20210921101014.1938382-5-elver@google.com> From: Dmitry Vyukov Date: Tue, 21 Sep 2021 12:51:21 +0200 Message-ID: Subject: Re: [PATCH v2 5/5] kfence: add note to documentation about skipping covered allocations To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , Jann Horn , Aleksandr Nogikh , Taras Madan , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 21 Sept 2021 at 12:10, Marco Elver wrote: > > Add a note briefly mentioning the new policy about "skipping currently > covered allocations if pool close to full." Since this has a notable > impact on KFENCE's bug-detection ability on systems with large uptimes, > it is worth pointing out the feature. > > Signed-off-by: Marco Elver Reviewed-by: Dmitry Vyukov > --- > v2: > * Rewrite. > --- > Documentation/dev-tools/kfence.rst | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/dev-tools/kfence.rst b/Documentation/dev-tools/kfence.rst > index 0fbe3308bf37..d45f952986ae 100644 > --- a/Documentation/dev-tools/kfence.rst > +++ b/Documentation/dev-tools/kfence.rst > @@ -269,6 +269,17 @@ tail of KFENCE's freelist, so that the least recently freed objects are reused > first, and the chances of detecting use-after-frees of recently freed objects > is increased. > > +If pool utilization reaches 75% (default) or above, to reduce the risk of the > +pool eventually being fully occupied by allocated objects yet ensure diverse > +coverage of allocations, KFENCE limits currently covered allocations of the > +same source from further filling up the pool. The "source" of an allocation is > +based on its partial allocation stack trace. A side-effect is that this also > +limits frequent long-lived allocations (e.g. pagecache) of the same source > +filling up the pool permanently, which is the most common risk for the pool > +becoming full and the sampled allocation rate dropping to zero. The threshold > +at which to start limiting currently covered allocations can be configured via > +the boot parameter ``kfence.skip_covered_thresh`` (pool usage%). > + > Interface > --------- > > -- > 2.33.0.464.g1972c5931b-goog >