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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9084BC3DA4A for ; Sat, 3 Aug 2024 14:52:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A15E6B008C; Sat, 3 Aug 2024 10:52:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9515A6B0092; Sat, 3 Aug 2024 10:52:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F2036B0093; Sat, 3 Aug 2024 10:52:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5FA0F6B008C for ; Sat, 3 Aug 2024 10:52:29 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id CE58E1611F3 for ; Sat, 3 Aug 2024 14:52:28 +0000 (UTC) X-FDA: 82411225176.10.3EDCE9A Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) by imf23.hostedemail.com (Postfix) with ESMTP id 283EE140016 for ; Sat, 3 Aug 2024 14:52:26 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=NNBi6C8a; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of elver@google.com designates 209.85.221.181 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722696681; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=M5wjK5I4/xcaavsdBTsn+WUUr3wkyX/2Ze1oBN2FQzo=; b=wrZlEpE89xuJwg0/Zly9lMPQXvRbx6nKyaOPRQ3ddQ2B2RYSQ57Xmecw2FAVr/EapqFhLy hqVy05AnTj2MSQ9V/99pzZEAkdx8KhEcd1wXGKafUf5/Iks/z6QlKXHnjhqGEUqQgL7Feg xgT25mzi7AI0RpSmF0BeeXKz7JxFfos= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722696681; a=rsa-sha256; cv=none; b=rn7ovh7u7KzMnA4wPBfcv82rML3YOTwHfoEa1HnJJAOxrRKLcyPb6GwqeqtRy1mAb52pgk DxCwQf4YsmS37xCkt4wlyKtK8LB2eYGYH4dZS4fTuo9/pn2OLAgVE3Z9p0x4IfY36vkmWX b/SLtKcAdI9axPPucswVYYW9Q0mYzO8= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=NNBi6C8a; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of elver@google.com designates 209.85.221.181 as permitted sender) smtp.mailfrom=elver@google.com Received: by mail-vk1-f181.google.com with SMTP id 71dfb90a1353d-4f89c9a1610so971533e0c.3 for ; Sat, 03 Aug 2024 07:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722696746; x=1723301546; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=M5wjK5I4/xcaavsdBTsn+WUUr3wkyX/2Ze1oBN2FQzo=; b=NNBi6C8a4c6qS1Oe6S/3WLc7b7rw5ZorH8es6MQbmNnfxPSb2BMWV9Ekcjbcuuq3l5 rsvXhhctHY7pDv8A2OXYDyhaZSkI+FovhnQ9XntxZGqkxboAtxiLyqV/oTl5yoOntEB8 w19uvqI/r+FHL1+3NMX4C24CSQwH3B/1KeDWiZF1rLKUgz0oeLASywDkBUwD+rTafR8A lCur4TAKeYskOsoddHpYDXK6uChVSORLmConghYGcxNfnw/CnNQdkidMYIbfq/KZSLcY Ms5xxWnECw16IkrLjfIN4S5vvzUi3tPVVSM4UV4eEuWNx0b5C+OFg2s07b1VlKHj1Wlf hfEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722696746; x=1723301546; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=M5wjK5I4/xcaavsdBTsn+WUUr3wkyX/2Ze1oBN2FQzo=; b=pzph3vgU9bBGabHQm/T5DJk2TwRS8PT2y/Nk84zFG0CSu4CVTEhATtFxpIna7BHL3u 1IO4KhkwM+mbjL65XJ2pBSz+2okrwSraJxbvqLTAruhsdEpvrBgCgLweJVGq/Ec60qaE MPvrMhVEp/tZN9Zi/UmuAWm73fFOnhrVKZGT9K2+WE/M+Z2hh/KRuIbtPJMGszSZ7TRG ersKV7p6FMxAsgHBjmj2l6IsVReUfU00QYloYOJ3ZISc5SDBm4NYTaBJxNSotq70ChJM afRVgdDMca/FdzshxUfhZi1a3JQX0L7+R/1/8y2L42PldbKe4CCNGPxFpsCTqFVSRHgX kmhQ== X-Forwarded-Encrypted: i=1; AJvYcCVttizfSbCl3mPf3ZeR7s7r23oo8BEcvkiaJc4ulcQVsFjRv57o/bIKHbBvt2ATicFekejKwxL/yRZ7TNCYKyXsE9o= X-Gm-Message-State: AOJu0YyuZhNYTrJ7mqQq9F8U/JwsbDVpYgzFBLFZXKat3tAlD+dsjPW9 nPOZLqUGCfaVvVVrRgefWyijvKJjb1qTRSuqXL/ZupbRYiNJb/GvcC3z5SjLHEM6DBAGJ4jtNXE HfXp6V28SKxYwo+aV5rjR+/P7XjcjIhmtCnPy X-Google-Smtp-Source: AGHT+IE+l1HJ7ULO6hm32fwjCszDie6Bd3ebe6gAiZgfsGpLamV8Q0FeGZ4ZLRszy9SjCun+CL1rfMhuyzcZb5q3M4c= X-Received: by 2002:a05:6122:291c:b0:4f5:cd00:e492 with SMTP id 71dfb90a1353d-4f89ff4e8b7mr8061621e0c.7.1722696745916; Sat, 03 Aug 2024 07:52:25 -0700 (PDT) MIME-Version: 1.0 References: <20240803133608.2124-1-chenqiwu@xiaomi.com> In-Reply-To: <20240803133608.2124-1-chenqiwu@xiaomi.com> From: Marco Elver Date: Sat, 3 Aug 2024 16:51:45 +0200 Message-ID: Subject: Re: [PATCH] mm: kfence: print the age time for alloacted objectes to trace memleak To: Qiwu Chen Cc: glider@google.com, dvyukov@google.com, akpm@linux-foundation.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, "qiwu.chen" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 283EE140016 X-Stat-Signature: s5ny1hy1cydtncq6ps9p16ksynrd9ejd X-Rspam-User: X-HE-Tag: 1722696746-508162 X-HE-Meta: U2FsdGVkX18Zb14gXAdD5uEY3yRNEttgeF7jrQfwYGvMVlkMCgr4uwYxuOZ0iDJRaljWGsz6+srpGf8E0MBWYXCYrn/0TlWr9NnOKFi3zyB6pd4Lyrv4w1tMJ5DhQyI82G3+hciUEQ0eohPcyJP9GZCwn1+gia6FX3UPnE5e7yoaw9yA5AJhyxVEvRMGw9/S0XGDippZGwo4KcqCtTTZ+J2dYhSclKtOjkh8nzX3659EiBaheIZLdRwqNhqFtIRDwNL+abWxrBx119MkqczGVtSkD9pIix8z0q1CaDgRCvqHfIZv0PdJEgVFxQFOIVfpX0rLCgrZ9bNTzSnb1OuXcwlxpX9x6p6JCCy7dsZJFAS5r4S4RF9uJnzmOh/QqTU1moh9xEooqYWjNOzV6HS1GNkN5ipbuov8WoBjxuPDYRXxkftirlE8IFiM4y6Hc5QsSX1u2oXQ4orCc4Czw2ZXOPJABxm4bFac81/f4ZNbIhYduFi1ftjqi0Wj0hWsTkkQgGF5EOgu2XUNC7mnI0gse4m5F1Qzut28PTlw6hHH8sCS/OKlnNsVgSFJkJlB9vYp+Mma4TWYFN2qKYZcVGLksmkQ0O13RJkQiie0yzB6IhDJEDZXYnRwVnuWoinnBmNj3qR55xLiO0EyBkmeosC3FTR5l8xs5e6eTHRZEbtoGhzq2d/VCNafhbVXP7+tX69Pb5iPXaEGt+86NMwoG/W069FKdjXHv6xgzL8xh1bRBGIo+oa5BK0SuMV50Of0rbY+dDLDwWSSC6rZkRL9vL1NJKdmcFRGut/mphl1QGQaAab1MkcdRsUeFWUimZLsr+VLzuKIbqwoB7WwXpuWITCQ8kQOvlcECls2i9lTyJ8af617gGnoRqWdQ27DRpSy2vls0E8U8Fx3FH5pcJOtOTubYiTwa08QhAysxXJ07+fkARaFNyT9/d1KwS5DEWGVZXMTqfmijG7r7FjwS3gJm3E NYh+jLXU Djrndm9M6e7uPRjwl3C9WviJhH8UtSJ5nNyWIxJOXD7jT22l5QCTT2a3ZJbwuG9hx4JCu3EHHfAXNyM4LYnSPnOKonDwoa5PixOYz4xX7XBHTg9i9z0s74TOzBrYg6Ei2dEVDKro/lZPax/OauZMi5AaIrcdZ1W0jwX7AXjLhUKXJB5rMDdD0Wre3luoPPgk9QSWHAaFCsluJJ0KAriUh/znPfzmIE4FYghF3QXDLJSuesDC/KFpqvhZoI9bHO/hJgA7o X-Bogosity: Ham, tests=bogofilter, spamicity=0.030374, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, 3 Aug 2024 at 15:36, Qiwu Chen wrote: > > From: "qiwu.chen" > > For a convienince of tracing slab object leak, print the age time for typo: convenience What do you mean by "object leak"? >From what I see the additional info is only printed on out-of-bounds access. Or do you mean when you inspect /sys/kernel/debug/kfence/objects? If so, that information would be useful in the commit message. However, to detect leaks there are better tools than KFENCE. Have you tried KMEMLEAK? KFENCE is really not a good choice to manually look for old objects, which themselves are sampled, to find leaks. Have you been able to successfully debug a leak this way? > alloacted objectes in kfence_print_stack(). typo: allocated objects > Signed-off-by: qiwu.chen > --- > mm/kfence/report.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/mm/kfence/report.c b/mm/kfence/report.c > index c509aed326ce..44c3f82b25a8 100644 > --- a/mm/kfence/report.c > +++ b/mm/kfence/report.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include > > #include > @@ -110,9 +111,18 @@ static void kfence_print_stack(struct seq_file *seq, const struct kfence_metadat > unsigned long rem_nsec = do_div(ts_sec, NSEC_PER_SEC); > > /* Timestamp matches printk timestamp format. */ > - seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus:\n", > + if (meta->state == KFENCE_OBJECT_ALLOCATED) { In principle, the additonal info is convenient, but I'd like to generalize if possible. > + u64 interval_nsec = local_clock() - meta->alloc_track.ts_nsec; > + unsigned long rem_interval_nsec = do_div(interval_nsec, NSEC_PER_SEC); > + > + seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus (age: %lu.%06lus):\n", I've found myself trying to figure out the elapsed time since the allocation or free, based on the current timestamp. So something that would be more helpful is if you just change the printed line for all alloc and free stack infos to say something like: seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus (%lu.%06lus ago):\n", So rather than saying this info is the "age", we just say the elapsed time. That generalizes this bit of info, and it'll be available for both alloc and free stacks. Does that work for you? > show_alloc ? "allocated" : "freed", track->pid, > - track->cpu, (unsigned long)ts_sec, rem_nsec / 1000); > + track->cpu, (unsigned long)ts_sec, rem_nsec / 1000, > + (unsigned long)interval_nsec, rem_interval_nsec / 1000); > + } else Add braces {} even though it's a single statement - it spans several lines and the above is also {}-enclosed, so it looks balanced. But if you follow my suggestion, you won't have the else branch anymore. > + seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus:\n", > + show_alloc ? "allocated" : "freed", track->pid, > + track->cpu, (unsigned long)ts_sec, rem_nsec / 1000); > > if (track->num_stack_entries) { > /* Skip allocation/free internals stack. */