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=-23.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 C6D18C433EF for ; Fri, 17 Sep 2021 12:59:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9BDA161269 for ; Fri, 17 Sep 2021 12:59:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240723AbhIQNAn (ORCPT ); Fri, 17 Sep 2021 09:00:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244946AbhIQNAd (ORCPT ); Fri, 17 Sep 2021 09:00:33 -0400 Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79652C0613DF for ; Fri, 17 Sep 2021 05:58:43 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id n27so13920171oij.0 for ; Fri, 17 Sep 2021 05:58:43 -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=+0q9dMDiPL7l1Xvh/pCQyuBurf5KBV4txXHcebk3J7o=; b=ohm9YZmHRMwJytXYWGsib848qv2LuXyfVNj9Rfnwh4O/AnsOZuhEpoKTBsRnAOSe27 rhuyFk06DuhpGHFvguVRPECEWimf0x1ipOriE1T6yIf+H2fOpigyuJFHWtQAapj06rFI vBRWqICiQ9/HifxhnF1CAKmJbTo0Y+DddrHt36tVt1LOlreMPPXM5vwVBki0BoLSNkVz GlxEWd04wa5ieQYw1IyJ0vUnYqcJNm8BZRF2PoPzeof0gkgJAd4qxR2Tp3mSc9IrHSvr tYe66phQ6IA/lCym2y8btng9z4KycuKjxq8CmIg66NOksUmP5Jherl+in69QTI1d5UXp YOjA== 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=+0q9dMDiPL7l1Xvh/pCQyuBurf5KBV4txXHcebk3J7o=; b=4OQYq+KKp8a+L4x/9uiOq4afBllMque2l2xQLJagJbZ3sA7lZ3PuFSk9M+ZNAkcNdc pw0rJ53vysS6LxmJTIH4+jodx2x0UMwUT35zH/QZKM6GEJrl5hiLqyhwwMXvYt1FRfZw DbcM6KXYxsqH5mwOb7iFtDCNVc0519CahpmUw8VTOUXlVwFCdNjboSbEpJ6/4TdL6bw0 zyyqAKLwDc2RDAiGoS/V3SBsFgGqpjMYzU9TLe9V2s9nPS6PL/LTairydea4bKndONY7 udI+5kqvxXAo9nezck3HRlK9QkXfVvTSyNpYWiehlLtBWbEAB3tRss/iUDuBCoGmVOFe P92g== X-Gm-Message-State: AOAM530Wta8AUT1xVaFAz0rauPPEpGnMamf9nT8BQXguhqi9weL3RI2a 9holzZMZB2C14cOIlWe4/6q8rTCfRFPsPu3CBk+D5g== X-Google-Smtp-Source: ABdhPJx6EkYfCT+AGBJzBynZrLClpn/6DUBafoMvuALv1yPubMRpPuqh+A8pH396wzHAoSzKRM7gxkBmSHJRKElQk+s= X-Received: by 2002:aca:1109:: with SMTP id 9mr3759856oir.109.1631883522559; Fri, 17 Sep 2021 05:58:42 -0700 (PDT) MIME-Version: 1.0 References: <20210917110756.1121272-1-elver@google.com> In-Reply-To: <20210917110756.1121272-1-elver@google.com> From: Dmitry Vyukov Date: Fri, 17 Sep 2021 14:58:30 +0200 Message-ID: Subject: Re: [PATCH 1/3] kfence: count unexpectedly skipped allocations To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , 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 Fri, 17 Sept 2021 at 13:08, 'Marco Elver' via kasan-dev wrote: > > Maintain a counter to count allocations that are skipped due to being > incompatible (oversized, incompatible gfp flags) or no capacity. > > This is to compute the fraction of allocations that could not be > serviced by KFENCE, which we expect to be rare. > > Signed-off-by: Marco Elver > --- > mm/kfence/core.c | 20 ++++++++++++++++---- > 1 file changed, 16 insertions(+), 4 deletions(-) > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > index 7a97db8bc8e7..2755800f3e2a 100644 > --- a/mm/kfence/core.c > +++ b/mm/kfence/core.c > @@ -112,6 +112,8 @@ enum kfence_counter_id { > KFENCE_COUNTER_FREES, > KFENCE_COUNTER_ZOMBIES, > KFENCE_COUNTER_BUGS, > + KFENCE_COUNTER_SKIP_INCOMPAT, > + KFENCE_COUNTER_SKIP_CAPACITY, > KFENCE_COUNTER_COUNT, > }; > static atomic_long_t counters[KFENCE_COUNTER_COUNT]; > @@ -121,6 +123,8 @@ static const char *const counter_names[] = { > [KFENCE_COUNTER_FREES] = "total frees", > [KFENCE_COUNTER_ZOMBIES] = "zombie allocations", > [KFENCE_COUNTER_BUGS] = "total bugs", > + [KFENCE_COUNTER_SKIP_INCOMPAT] = "skipped allocations (incompatible)", > + [KFENCE_COUNTER_SKIP_CAPACITY] = "skipped allocations (capacity)", > }; > static_assert(ARRAY_SIZE(counter_names) == KFENCE_COUNTER_COUNT); > > @@ -272,7 +276,7 @@ static void *kfence_guarded_alloc(struct kmem_cache *cache, size_t size, gfp_t g > } > raw_spin_unlock_irqrestore(&kfence_freelist_lock, flags); > if (!meta) > - return NULL; > + goto no_capacity; > > if (unlikely(!raw_spin_trylock_irqsave(&meta->lock, flags))) { > /* > @@ -289,7 +293,7 @@ static void *kfence_guarded_alloc(struct kmem_cache *cache, size_t size, gfp_t g > list_add_tail(&meta->list, &kfence_freelist); > raw_spin_unlock_irqrestore(&kfence_freelist_lock, flags); > > - return NULL; > + goto no_capacity; Do we expect this case to be so rare that we don't care? Strictly speaking it's not no_capacity. So if I see large no_capacity numbers, the first question I will have is: is it really no_capacity, or some other case that we mixed together? > } > > meta->addr = metadata_to_pageaddr(meta); > @@ -349,6 +353,10 @@ static void *kfence_guarded_alloc(struct kmem_cache *cache, size_t size, gfp_t g > atomic_long_inc(&counters[KFENCE_COUNTER_ALLOCS]); > > return addr; > + > +no_capacity: > + atomic_long_inc(&counters[KFENCE_COUNTER_SKIP_CAPACITY]); > + return NULL; > } > > static void kfence_guarded_free(void *addr, struct kfence_metadata *meta, bool zombie) > @@ -740,8 +748,10 @@ void *__kfence_alloc(struct kmem_cache *s, size_t size, gfp_t flags) > * Perform size check before switching kfence_allocation_gate, so that > * we don't disable KFENCE without making an allocation. > */ > - if (size > PAGE_SIZE) > + if (size > PAGE_SIZE) { > + atomic_long_inc(&counters[KFENCE_COUNTER_SKIP_INCOMPAT]); > return NULL; > + } > > /* > * Skip allocations from non-default zones, including DMA. We cannot > @@ -749,8 +759,10 @@ void *__kfence_alloc(struct kmem_cache *s, size_t size, gfp_t flags) > * properties (e.g. reside in DMAable memory). > */ > if ((flags & GFP_ZONEMASK) || > - (s->flags & (SLAB_CACHE_DMA | SLAB_CACHE_DMA32))) > + (s->flags & (SLAB_CACHE_DMA | SLAB_CACHE_DMA32))) { > + atomic_long_inc(&counters[KFENCE_COUNTER_SKIP_INCOMPAT]); > return NULL; > + } > > /* > * allocation_gate only needs to become non-zero, so it doesn't make > -- > 2.33.0.464.g1972c5931b-goog > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210917110756.1121272-1-elver%40google.com. 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=-23.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham 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 16AD6C433FE for ; Fri, 17 Sep 2021 12:58:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B153261130 for ; Fri, 17 Sep 2021 12:58:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B153261130 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 4442E6B0071; Fri, 17 Sep 2021 08:58:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F0E76B0072; Fri, 17 Sep 2021 08:58:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2925C900002; Fri, 17 Sep 2021 08:58:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) by kanga.kvack.org (Postfix) with ESMTP id 1B0066B0071 for ; Fri, 17 Sep 2021 08:58:44 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CD924181F0161 for ; Fri, 17 Sep 2021 12:58:43 +0000 (UTC) X-FDA: 78597069726.28.89446FD Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) by imf18.hostedemail.com (Postfix) with ESMTP id 7633C400208F for ; Fri, 17 Sep 2021 12:58:43 +0000 (UTC) Received: by mail-oi1-f177.google.com with SMTP id p2so13881013oif.1 for ; Fri, 17 Sep 2021 05:58:43 -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=+0q9dMDiPL7l1Xvh/pCQyuBurf5KBV4txXHcebk3J7o=; b=ohm9YZmHRMwJytXYWGsib848qv2LuXyfVNj9Rfnwh4O/AnsOZuhEpoKTBsRnAOSe27 rhuyFk06DuhpGHFvguVRPECEWimf0x1ipOriE1T6yIf+H2fOpigyuJFHWtQAapj06rFI vBRWqICiQ9/HifxhnF1CAKmJbTo0Y+DddrHt36tVt1LOlreMPPXM5vwVBki0BoLSNkVz GlxEWd04wa5ieQYw1IyJ0vUnYqcJNm8BZRF2PoPzeof0gkgJAd4qxR2Tp3mSc9IrHSvr tYe66phQ6IA/lCym2y8btng9z4KycuKjxq8CmIg66NOksUmP5Jherl+in69QTI1d5UXp YOjA== 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=+0q9dMDiPL7l1Xvh/pCQyuBurf5KBV4txXHcebk3J7o=; b=mJDbxI4/AW/oN698UlHVXjAYvLHO8s3Qt2mjtEvvZiTnTp7xNWov9Rj+dL32hEaUFo uTPQnAgd6zLbGkRMfYJjL6in7LDE+ip217KQwpFuFuL4ncolIzGdNkNLXC5XMsBizTG3 RmSerUxmB7VCM+OBwxxV/K9Kyh4TIZ5u1X9YndpzChMdhzvBg9q/a2sJv7xAE2cMYACm NZ6/TwAbxw2gyQkftyJf7qMIz9GwZhPG/matwMVWicNzO3rP1nWCeE3lb8mIP+7f2fAP s3iA67OvLvES9NgNr3wWMgQEprkscPgmzB8I+a+8C9xKhtQerinRIBwd1NAWaq3wPJHq K4nw== X-Gm-Message-State: AOAM533+wO4iUWGadz182KYE54D2Mf2N2FvwsVj7jaYr7r0+sK0pfJRh bp+jt74cWD2VFPjx04w0gNOLknF4oP5viqu1H3xYPg== X-Google-Smtp-Source: ABdhPJx6EkYfCT+AGBJzBynZrLClpn/6DUBafoMvuALv1yPubMRpPuqh+A8pH396wzHAoSzKRM7gxkBmSHJRKElQk+s= X-Received: by 2002:aca:1109:: with SMTP id 9mr3759856oir.109.1631883522559; Fri, 17 Sep 2021 05:58:42 -0700 (PDT) MIME-Version: 1.0 References: <20210917110756.1121272-1-elver@google.com> In-Reply-To: <20210917110756.1121272-1-elver@google.com> From: Dmitry Vyukov Date: Fri, 17 Sep 2021 14:58:30 +0200 Message-ID: Subject: Re: [PATCH 1/3] kfence: count unexpectedly skipped allocations To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , Aleksandr Nogikh , Taras Madan , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ohm9YZmH; spf=pass (imf18.hostedemail.com: domain of dvyukov@google.com designates 209.85.167.177 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: c3coecxhgq7jg483pkczbad5wxaycrrg X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7633C400208F X-HE-Tag: 1631883523-843160 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 Fri, 17 Sept 2021 at 13:08, 'Marco Elver' via kasan-dev wrote: > > Maintain a counter to count allocations that are skipped due to being > incompatible (oversized, incompatible gfp flags) or no capacity. > > This is to compute the fraction of allocations that could not be > serviced by KFENCE, which we expect to be rare. > > Signed-off-by: Marco Elver > --- > mm/kfence/core.c | 20 ++++++++++++++++---- > 1 file changed, 16 insertions(+), 4 deletions(-) > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > index 7a97db8bc8e7..2755800f3e2a 100644 > --- a/mm/kfence/core.c > +++ b/mm/kfence/core.c > @@ -112,6 +112,8 @@ enum kfence_counter_id { > KFENCE_COUNTER_FREES, > KFENCE_COUNTER_ZOMBIES, > KFENCE_COUNTER_BUGS, > + KFENCE_COUNTER_SKIP_INCOMPAT, > + KFENCE_COUNTER_SKIP_CAPACITY, > KFENCE_COUNTER_COUNT, > }; > static atomic_long_t counters[KFENCE_COUNTER_COUNT]; > @@ -121,6 +123,8 @@ static const char *const counter_names[] = { > [KFENCE_COUNTER_FREES] = "total frees", > [KFENCE_COUNTER_ZOMBIES] = "zombie allocations", > [KFENCE_COUNTER_BUGS] = "total bugs", > + [KFENCE_COUNTER_SKIP_INCOMPAT] = "skipped allocations (incompatible)", > + [KFENCE_COUNTER_SKIP_CAPACITY] = "skipped allocations (capacity)", > }; > static_assert(ARRAY_SIZE(counter_names) == KFENCE_COUNTER_COUNT); > > @@ -272,7 +276,7 @@ static void *kfence_guarded_alloc(struct kmem_cache *cache, size_t size, gfp_t g > } > raw_spin_unlock_irqrestore(&kfence_freelist_lock, flags); > if (!meta) > - return NULL; > + goto no_capacity; > > if (unlikely(!raw_spin_trylock_irqsave(&meta->lock, flags))) { > /* > @@ -289,7 +293,7 @@ static void *kfence_guarded_alloc(struct kmem_cache *cache, size_t size, gfp_t g > list_add_tail(&meta->list, &kfence_freelist); > raw_spin_unlock_irqrestore(&kfence_freelist_lock, flags); > > - return NULL; > + goto no_capacity; Do we expect this case to be so rare that we don't care? Strictly speaking it's not no_capacity. So if I see large no_capacity numbers, the first question I will have is: is it really no_capacity, or some other case that we mixed together? > } > > meta->addr = metadata_to_pageaddr(meta); > @@ -349,6 +353,10 @@ static void *kfence_guarded_alloc(struct kmem_cache *cache, size_t size, gfp_t g > atomic_long_inc(&counters[KFENCE_COUNTER_ALLOCS]); > > return addr; > + > +no_capacity: > + atomic_long_inc(&counters[KFENCE_COUNTER_SKIP_CAPACITY]); > + return NULL; > } > > static void kfence_guarded_free(void *addr, struct kfence_metadata *meta, bool zombie) > @@ -740,8 +748,10 @@ void *__kfence_alloc(struct kmem_cache *s, size_t size, gfp_t flags) > * Perform size check before switching kfence_allocation_gate, so that > * we don't disable KFENCE without making an allocation. > */ > - if (size > PAGE_SIZE) > + if (size > PAGE_SIZE) { > + atomic_long_inc(&counters[KFENCE_COUNTER_SKIP_INCOMPAT]); > return NULL; > + } > > /* > * Skip allocations from non-default zones, including DMA. We cannot > @@ -749,8 +759,10 @@ void *__kfence_alloc(struct kmem_cache *s, size_t size, gfp_t flags) > * properties (e.g. reside in DMAable memory). > */ > if ((flags & GFP_ZONEMASK) || > - (s->flags & (SLAB_CACHE_DMA | SLAB_CACHE_DMA32))) > + (s->flags & (SLAB_CACHE_DMA | SLAB_CACHE_DMA32))) { > + atomic_long_inc(&counters[KFENCE_COUNTER_SKIP_INCOMPAT]); > return NULL; > + } > > /* > * allocation_gate only needs to become non-zero, so it doesn't make > -- > 2.33.0.464.g1972c5931b-goog > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210917110756.1121272-1-elver%40google.com.