Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp698177pxb; Thu, 23 Sep 2021 08:51:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmiKPGmEz0aAKsJPkdUjWYCqWBxNDPERwhGy9FZwvbmmIxcFufWhw1Q0kTsq/zHIgTf20n X-Received: by 2002:a17:906:774f:: with SMTP id o15mr5649059ejn.200.1632412302511; Thu, 23 Sep 2021 08:51:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632412302; cv=none; d=google.com; s=arc-20160816; b=n0ExW7TOyZUXfXcWAdbNEGMKDYLHRQjP0OGkoaH0WcHhJQSW1pFguF4wn7ktxG9eAS PA7I+RJUyyQM7G1zy9C7xf2/msBHcxxAwYuaLUoiBhePupFcs2ILk0LZGGebnDKktPYd fDSAYqAwraYXBj9/yja4BZ9jYU4mNAEc93SUjlrJUARSAYJ48XOAwItymRC9zyQAOlad 09lAVOPXdQIHF7+vNCmqAk5bxzo+qR/fwysFjmkozsXbA2Scc+8cg6g1BJejfvUpnVeq mLV6kpFbm6Q+YsncPHpNJ7H/sFSnm0HtME2w+tbd5/hksUe+/JdP9PxNsb8X03MtgQIp vLgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=mQ7J4946rPgf21nD+uOWBbdKEn3T7TjKfOLDKhMFyj8=; b=CpQX0jGv5KfuQ2+S8jhMI6YPDR57caOaEz4Ar8XK+HjKAExvftkvEOYg6yGNczH45w IuqeHT0GFUU67LmmKFL2/2ls7alYPDc0MQHTPhdUNDUbmqh2vgV8uZ1G9tgrzZzJnZ+X l40QznldymKQqcdesVRHKaRzrSZ7TbATBWrbasn0YFpnWgBNBhGlRyimwy5PeQ6ASJUS BRdHyzGs905f0OIeQe7eHJeSwY6ac08Cbi/8Rp+cEkOtVEKehG4+9ImFXYG+g1NnX4Pw BIzX73LpDl9ttycpjD1ueEaO/HX3HK5bJobg5Qc5QHEi1Ez0fQzQqYcu/o0Xr6gBo3Zv gY1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=mTZSIMO+; 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 g5si7679003ejo.390.2021.09.23.08.51.16; Thu, 23 Sep 2021 08:51:42 -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=mTZSIMO+; 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 S242262AbhIWPvQ (ORCPT + 99 others); Thu, 23 Sep 2021 11:51:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242232AbhIWPuX (ORCPT ); Thu, 23 Sep 2021 11:50:23 -0400 Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3754DC0613E8 for ; Thu, 23 Sep 2021 08:47:28 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id t2so72449qtx.8 for ; Thu, 23 Sep 2021 08:47:28 -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:content-transfer-encoding; bh=mQ7J4946rPgf21nD+uOWBbdKEn3T7TjKfOLDKhMFyj8=; b=mTZSIMO+GVE3tAo3UxQ/EEydBd45P0gIJQPxkrgTq8B0UZCXkEnrSWUJW6upsdbj4b Q+S46nBbvfjWhrTOs9o+HrBmHAMZFTUytwznDahlXAoqa6qg2MP6vaNyZOuChN1SRFzu Un9VKdQg/TUxiTBWNI0FymudM9q9M79nvZMV18kDxdGSmdlbfEsK04lmbBG3KPQbo3kc erEjMADzPxqjpSJ+2+q9x2dp/eJSDp1B5NrA4Px5JDxD81H+BhV6mFTLHWxar5Xm6nVt ZeIvmSvzBEvV2nEiQKYQ0J1EFw3GxobotbcFK7had7vcG47cyKj4Ykd6r9gH51AEzJqp Oz/Q== 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:content-transfer-encoding; bh=mQ7J4946rPgf21nD+uOWBbdKEn3T7TjKfOLDKhMFyj8=; b=ANceBfLKw85YLGzwIQAP11EwyfO12qXHSxNhkYssn/1/rOxpRzf8MUTScuzNk8uBWK /RiC3dbnr54VMzptRs+zRfuSVYRVXB93oLaCZhBctRDtrz9VMQBhjuohlxZWkXpJryTN 1G+UAy5BAsPFtS+CZ3OFaXI8dHBWHta/fxrvcZnAbDItaCEc1sbbS7pOYszsTYdcaS58 aqLM+gcYeM7iXiExCwrncmuyv7oCDeeHe6M8oET8z7aOv1Mg6SS0/PyAum0bZJ80XP/u xEiyAEJTgBmwR34Wk1Zh12CYzk11AncgRBBq5yk6Zn9Gc/0dtNfmmaVRKngZPuq56TQ3 b4xQ== X-Gm-Message-State: AOAM532Zx0Id7vUeiWSNlqi9oQ4v9ZwlMlwXS8UGW2fiwTDz+ppsR9In qqjcAy2b/sxYWWliGP6RM3lYQD22xzCAQqbepDG+UHWNFRo= X-Received: by 2002:ac8:7482:: with SMTP id v2mr5389401qtq.235.1632412047701; Thu, 23 Sep 2021 08:47:27 -0700 (PDT) MIME-Version: 1.0 References: <20210923104803.2620285-1-elver@google.com> <20210923104803.2620285-5-elver@google.com> In-Reply-To: <20210923104803.2620285-5-elver@google.com> From: Alexander Potapenko Date: Thu, 23 Sep 2021 17:46:51 +0200 Message-ID: Subject: Re: [PATCH v3 5/5] kfence: add note to documentation about skipping covered allocations To: Marco Elver Cc: Andrew Morton , Dmitry Vyukov , Jann Horn , Aleksandr Nogikh , Taras Madan , LKML , Linux Memory Management List , kasan-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 23, 2021 at 12:48 PM 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 Acked-by: Alexander Potapenko > --- > 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 recentl= y freed objects are reused > first, and the chances of detecting use-after-frees of recently freed ob= jects > is increased. > > +If pool utilization reaches 75% (default) or above, to reduce the risk o= f the > +pool eventually being fully occupied by allocated objects yet ensure div= erse > +coverage of allocations, KFENCE limits currently covered allocations of = the > +same source from further filling up the pool. The "source" of an allocat= ion 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 sour= ce > +filling up the pool permanently, which is the most common risk for the p= ool > +becoming full and the sampled allocation rate dropping to zero. The thre= shold > +at which to start limiting currently covered allocations can be configur= ed via > +the boot parameter ``kfence.skip_covered_thresh`` (pool usage%). > + > Interface > --------- > > -- > 2.33.0.464.g1972c5931b-goog > --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg