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 D7C35C38A02 for ; Fri, 28 Oct 2022 13:57:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB40B6B0071; Fri, 28 Oct 2022 09:57:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3C496B0073; Fri, 28 Oct 2022 09:57:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2B616B0074; Fri, 28 Oct 2022 09:57:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BFC876B0071 for ; Fri, 28 Oct 2022 09:57:05 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 62993C0594 for ; Fri, 28 Oct 2022 13:57:05 +0000 (UTC) X-FDA: 80070509610.23.9E07B9F Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf21.hostedemail.com (Postfix) with ESMTP id D00A01C0019 for ; Fri, 28 Oct 2022 13:57:03 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0352BB82A34; Fri, 28 Oct 2022 13:57:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B47BBC433D6; Fri, 28 Oct 2022 13:56:58 +0000 (UTC) Date: Fri, 28 Oct 2022 14:56:55 +0100 From: Catalin Marinas To: "zhaoyang.huang" Cc: Andrew Morton , Matthew Wilcox , Nathan Chancellor , Nick Desaulniers , Tom Rix , Zhaoyang Huang , linux-mm@kvack.org, linux-kernel@vger.kernel.org, ke.wang@unisoc.com, steve.kang@unisoc.com Subject: Re: [RFC PATCH] mm: sort kmemleak object via backtrace Message-ID: References: <1664264570-3716-1-git-send-email-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1664264570-3716-1-git-send-email-zhaoyang.huang@unisoc.com> ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf21.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666965424; a=rsa-sha256; cv=none; b=MgtB7PW21+nLbZI7jIHozDlF2ZWpwvMNjTG0BZqFy8GzcQf36QrKu1IwBGSTSJ4DMqAUOc y+V88UUQH/keMgA7wz4IKVAkVwxDyXlSUGwLQbGoq+UECMd4wRd8IhrN/WCoaeqfh1+nNv UOzhwjoEiHo0Kgz3EDMkRjuFJweFdVw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666965424; 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; bh=FwRsNiBoN30MLrm10BPCsUvpZ79lYTB/Clw3lnPm9v8=; b=YVG+K8c74xQM0UwjoMNjw2bK5yUa/ukhZxN5pc8F8PGjS+QG0vJeVn+0Lqg7F0a4V0AfGj mY6ROxJUnvcuIsrB4dugQYYtwikwf16XyUuIHN9hGE4m0KmFscKcDWBOGZeZA6CcVUsi4t IYgQFRgS7grU75u6YIuWh8eG2S2eo8U= Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf21.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org X-Rspam-User: X-Stat-Signature: 8tzgw6b1qth49d345dkdf8ef93bcx4fm X-Rspamd-Queue-Id: D00A01C0019 X-Rspamd-Server: rspam11 X-HE-Tag: 1666965423-768875 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 Tue, Sep 27, 2022 at 03:42:50PM +0800, zhaoyang.huang wrote: > From: Zhaoyang Huang > > Kmemleak objects are reported each which could produce lot of redundant > backtrace informations. introduce a set of method to establish a hash > tree to sort the objects according to backtrace. > > results: > [ 579.075111]c6 [ T5491] kmemleak: unreferenced object 0xffffff80badd9e00 (size 128): > [ 579.082734]c6 [ T5491] kmemleak: comm "swapper/0", pid 1, jiffies 4294892470 > [ 579.096837]c6 [ T5491] kmemleak: unreferenced object 0xffffff80badd9d00 (size 128): > [ 579.104435]c6 [ T5491] kmemleak: comm "swapper/0", pid 1, jiffies 4294892470 > [ 579.118563]c6 [ T5491] kmemleak: unreferenced object 0xffffff80baddce80 (size 128): > [ 579.126201]c6 [ T5491] kmemleak: comm "swapper/0", pid 1, jiffies 4294892470 > [ 579.140303]c6 [ T5491] kmemleak: unreferenced object 0xffffff80baddcb00 (size 128): > [ 579.147906]c6 [ T5491] kmemleak: comm "swapper/0", pid 1, jiffies 4294892470 > [ 579.162032]c6 [ T5491] kmemleak: unreferenced object 0xffffff80bae74a80 (size 128): > [ 579.169661]c6 [ T5491] kmemleak: comm "swapper/0", pid 1, jiffies 4294892470 > [ 579.183775]c6 [ T5491] kmemleak: unreferenced object 0xffffff80bae74100 (size 128): > [ 579.191374]c6 [ T5491] kmemleak: comm "swapper/0", pid 1, jiffies 4294892471 > [ 579.205486]c6 [ T5491] kmemleak: unreferenced object 0xffffff80bae75880 (size 128): > [ 579.213127]c6 [ T5491] kmemleak: comm "swapper/0", pid 1, jiffies 4294892471 > [ 579.227743]c6 [ T5491] kmemleak: backtrace: > [ 579.232109]c6 [ T5491] kmemleak: [<0000000066492d96>] __kmalloc_track_caller+0x1d4/0x3e0 > [ 579.240506]c6 [ T5491] kmemleak: [<00000000e5400df8>] kstrdup_const+0x6c/0xa4 > [ 579.247930]c6 [ T5491] kmemleak: [<00000000d7843951>] __kernfs_new_node+0x5c/0x1dc > [ 579.255830]c6 [ T5491] kmemleak: [<0000000073b5a7bd>] kernfs_new_node+0x60/0xc4 > [ 579.263436]c6 [ T5491] kmemleak: [<000000002c7a48d5>] __kernfs_create_file+0x60/0xfc > [ 579.271485]c6 [ T5491] kmemleak: [<00000000260ae4a1>] cgroup_addrm_files+0x244/0x4b0 > [ 579.279534]c6 [ T5491] kmemleak: [<00000000ec6bce51>] css_populate_dir+0xb4/0x13c > [ 579.287324]c6 [ T5491] kmemleak: [<000000005913d698>] cgroup_mkdir+0x1e0/0x31c > [ 579.294859]c6 [ T5491] kmemleak: [<0000000052605ead>] kernfs_iop_mkdir.llvm.8836999160598622324+0xb0/0x168 > [ 579.304817]c6 [ T5491] kmemleak: [<0000000009665bc4>] vfs_mkdir+0xec/0x170 > [ 579.311990]c6 [ T5491] kmemleak: [<000000003c9c94c1>] do_mkdirat+0xa4/0x168 > [ 579.319279]c6 [ T5491] kmemleak: [<000000005dd5be19>] __arm64_sys_mkdirat+0x28/0x38 > [ 579.327242]c6 [ T5491] kmemleak: [<000000005a0b9381>] el0_svc_common+0xb4/0x188 > [ 579.334868]c6 [ T5491] kmemleak: [<0000000063586a51>] el0_svc_handler+0x2c/0x3c > [ 579.342472]c6 [ T5491] kmemleak: [<00000000edfd67aa>] el0_svc+0x8/0x100 I'm not convinced it's worth the complexity. Yes, it looks nicer, but if you have so many leaks they'd not go unnoticed and get fixed relatively quickly. One thing I liked about the kmemleak traces is that they are shown in the order they were allocated. On many occasions, one leak (or false positive) leaks to another, so it's easier to track them down if you start with the first. Is the order preserved with your patch? -- Catalin