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 29BC3C3DA4A for ; Mon, 5 Aug 2024 06:51:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 331426B007B; Mon, 5 Aug 2024 02:51:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E0146B0082; Mon, 5 Aug 2024 02:51:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CE706B0085; Mon, 5 Aug 2024 02:51:37 -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 05B616B007B for ; Mon, 5 Aug 2024 02:51:36 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8034416011C for ; Mon, 5 Aug 2024 06:51:36 +0000 (UTC) X-FDA: 82417270992.08.1936894 Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) by imf30.hostedemail.com (Postfix) with ESMTP id C2F5380002 for ; Mon, 5 Aug 2024 06:51:34 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uxFPtCKV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of elver@google.com designates 209.85.221.172 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=1722840626; 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=IUBNG1lIyvhInWPDctmqLdJ8JkiVZzYt8STEbPyqNN4=; b=Rj/H7dd69kjBf930zwzmU4VxEatrEZezuT7XWO83rgd9wwXpi1rI88uNCN9kQfFPrDz091 XqV2tq8prRyxil+s1jWmdQEX7NqG+culbk1rHFTdnXO+4Tbzja9iBIcPtWoGHnH3Mk33Bb Z01ha6FG6udunQRb3z5azmZzmljYk1Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722840626; a=rsa-sha256; cv=none; b=tX1BUtG4NPFMl8+e7mWooqaWM5c50Agspx69CVNaUIf3LC0OzOtqYCWRqAFRIAGZHH48KR QLb+0BLulNqF5MHX3I51Pe9KZUxbAtY5DzlCcB0I7GQmveI6iFdoMphRV4c89vUIwbHFC2 ZAo0AE4bukSQst8CUkPTXDEh7rER3Bg= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uxFPtCKV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of elver@google.com designates 209.85.221.172 as permitted sender) smtp.mailfrom=elver@google.com Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-4f8b5e5671bso437622e0c.0 for ; Sun, 04 Aug 2024 23:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722840694; x=1723445494; 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=IUBNG1lIyvhInWPDctmqLdJ8JkiVZzYt8STEbPyqNN4=; b=uxFPtCKVeUtEoPbn+xxpR8IwXqUj1Lw9Vko6XtjGLOmnNH/a9DEhT5BhLQbEhLQv9T 8MmS0fFS/JbIKpWr4l44nhfEMSefNsEbkqeH/4IqzfpAkmgDA6LSOHHtAehKqWAywmU7 kr0Y39VYMyGzoswAatwE0CyguKVDSduJmozbTVAUfNxKOZg1zj4TmCQhBhLQMwSvKgEE GLZUnHZNqAebS391ZTIMt+f6Lsx4DWvuclEv3+/rqC3BDS4adGHlnzsWEpPBOW3a2eJx vPuV6ZSFGPYH1EsBVBR8PriMmY9es+owyd93yIAAK7Xq0hoYJWGWY+0lQJ2RNLydtJmB E5EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722840694; x=1723445494; 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=IUBNG1lIyvhInWPDctmqLdJ8JkiVZzYt8STEbPyqNN4=; b=GXJIrix756S52u8sU0PGJJrF8eW2bPWDpcj/HDgrZyK9y8yJg7p/i4NZVii4GX0eK4 8prSPfIC/VPgV2y9IQqgA9QjbxmJdG6iuGM0hH4SW2vj3+tT45+o89IhdaPxxsp/RDX3 XYl2ZO3oL594HmEcjGdDNIENukGH3N7PsPQ3rmRq5F3l+eUrSzf2EIqF4W4QD89BmJGx dBFF3W8Tle5lFJYXOZC2sVaLvFG82LXnOhm7YUQu4RAt9TOqycHDh2RN5D7JUA9m17N8 tXUeslhOvdcT285OfH/bWJJ6lglCRVZ+gUHxZ9BVH5ywmel+M4ytmzNgm6ljesM/nm8j zt9w== X-Forwarded-Encrypted: i=1; AJvYcCUsReurI4JM1SV1lFxxPbJpxIvOuPSy0zA0UqehzcGATMz8Au85GPO/uBPCZgO+/N0Awi7NEcpaXepuym7LmZCGrJY= X-Gm-Message-State: AOJu0YyAf90NFoIghQyZNHzQKOmpWSfbO680+sxMeyzbElXCw6naHy/d TJCXZrhPtB74AIoss4mO6lD5KGjckXue++SRcrIlZLBNoTY0MfEa+s0ZBTY+Zy9Bh/4MSk22NDi sBh6dC7yHKgzJZZTyAYi+Hm7tbSGDrAqO3IFI X-Google-Smtp-Source: AGHT+IF5hF4pISXI9k5n3rTt1frLdEy6gZ7EGRB04mubYieLXHL2767EwXC/04Qe3uvem4xq3DtZ72p3laXt91sbRyk= X-Received: by 2002:a05:6122:4692:b0:4ec:f6f2:f1cd with SMTP id 71dfb90a1353d-4f8a00189b6mr8430275e0c.9.1722840693506; Sun, 04 Aug 2024 23:51:33 -0700 (PDT) MIME-Version: 1.0 References: <20240803133608.2124-1-chenqiwu@xiaomi.com> <20240804034607.GA11291@rlk> <20240805033534.GA15091@rlk> In-Reply-To: <20240805033534.GA15091@rlk> From: Marco Elver Date: Mon, 5 Aug 2024 08:50:57 +0200 Message-ID: Subject: Re: [PATCH] mm: kfence: print the age time for alloacted objectes to trace memleak To: chenqiwu Cc: glider@google.com, dvyukov@google.com, akpm@linux-foundation.org, kasan-dev@googlegroups.com, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C2F5380002 X-Stat-Signature: d3jdfmmggshhx74osopzpwr31mi9myrq X-Rspam-User: X-HE-Tag: 1722840694-515613 X-HE-Meta: U2FsdGVkX1/0sGZ9i55C60lqIuGvU2NIHd4B2nye5eHLyAh57bMlbqLsxlJqNAGmjswztJVuMAWpCgdZqXvyQ6rDpp8JtSoKxB+YwpSOL2qOh6EkMNshWt2gxzmbuMj9QhGCND1Wj19WxsKaPy9e7wvd3eQ2HqV2YPdzOquy5AwLRLo7h2C0fMQIutxYFIU6XFqlYcZSkTVR1dknhpYMRIUvHbOnFGsDjq66M/54yFF7I+qse6kiaGjh2bEXlRFzN6UYSPS2cVOoBmLK3l/vpC/VGWl9yo0gs+JHu+SVIMSvCyXtKI0zUJPRwARKPED13N1Khx74cZhfSo46/u0hFavox7HfW1a1RnBW48kBVXntM9YnAiSrdz9Yz2bnyspeYe8On4tqrwqtweZYx9E1pbstOeb+InG3Sw+hnmu8kaW5pGYv5glHWcM51ygujfdkwvhBD7qIAaDkRhrz2JiYoCsGIZVvoc4Uj3cbHVQfJ/Q4zdv9lvys3nJAMJ/0wNJUI6N39Bsp46GZe00li/fWV2cz7CvexuzFYMSmTY81XVvg2IfZZQllNXZ4ECDqujAn48nOrOkT8Hvns+j2TApFDPOjJDBuusVedonevACtl1DspCDaAL5Bljp8oqWE0Vc016MqdeOxk/QyJ3GvxG5XzqLvqXXr3747AuepSTA067PLKvOpprUGn1v0VOUUhjiu52AY+7yM5naOKDnIyj2KwwNZZI2kepOmNcx/wAV4wu8PIn3LYTt2TpqKLAzi//s4IJ6jELwIvZ00isITBdivCHOhHMD3dgGS/XUbLFo8TxuCcGBEJuKsCov+MxHSrQ/5hMMfL/mkJVl5x4KZeUWIYruJfrUYOIB/j9CRv1XGX+8mvpWtfkbp8p/G00yX6S8GTqNsCm3gh0du7KZbufcStCdTjedBXy6H/NwjJCWPioMRgJfG2HhgZ/JDSdvtxXE+GS+eYd4ESTwblEsByA+ BMPN5OJH TEa3iNqjVv5/7zIZMsUvEYu41YEHLCKZC9lHzN04p++OBCCApeoHuqwHnXx8ngT+QY57oFDLcoWcGOd/MyPb4b1AhRD6wDJmpzzkb3ahCM7jLiQI42gF6xSe7VEdaDJCYs6Niciyeobqtfu8EOgJtnsgYHfbc99k7LtHCUGt+u2bggASV4SEstKUCGchWnDEUN2eR X-Bogosity: Ham, tests=bogofilter, spamicity=0.009284, 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 Mon, 5 Aug 2024 at 05:35, chenqiwu wrote: > > On Sun, Aug 04, 2024 at 10:37:43AM +0200, Marco Elver wrote: > > > > Well, what I'm saying, having this info also for FREED objects on the > > free stack can be useful in some debugging scenarios when you get a > > use-after-free, and you want to know the elapsed time since the free > > happened. I have done this calculation manually before, which is why I > > suggested it. Maybe it's not useful for you for finding leaks, but > > that's just one usecase. > > > Agreed with your concern scenarios. > How about the following change with additonal object state info? > > + u64 interval_nsec = local_clock() - meta->alloc_track.ts_nsec; > + unsigned long rem_interval_nsec = do_div(interval_nsec, NSEC_PER_SEC); > > /* Timestamp matches printk timestamp format. */ > - seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus:\n", > + seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus (%lu.%06lus ago) for %s object:\n", > 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, > + meta->state == KFENCE_OBJECT_ALLOCATED? "allocated" : "freed"); > > In this way, we can find leaks by grep "allocated object" and inspect the elapsed time of > use-after-free by grep "freed object". The "allocated/freed" info is superfluous, as freed objects will have a free stack. Consider a slightly better script vs. just using grep. /sys/kernel/debug/kfence/objects is of secondary concern and was added primarily as a debugging aid for KFENCE developers. We never thought it could be used to look for leaks, but good you found another use for it. ;-) The priority is to keep regular error reports generated by KFENCE readable. Adding this "allocated/freed" info just makes the line longer and is not useful. I'm happy with the "(%lu.%06lus ago)" part alone.