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 86D48C3DA4A for ; Mon, 5 Aug 2024 14:19:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0BE546B007B; Mon, 5 Aug 2024 10:19:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 049C46B0082; Mon, 5 Aug 2024 10:19:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E29736B0085; Mon, 5 Aug 2024 10:19:28 -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 BE7F26B007B for ; Mon, 5 Aug 2024 10:19:28 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 64EB6A88F4 for ; Mon, 5 Aug 2024 14:19:28 +0000 (UTC) X-FDA: 82418399616.02.3865114 Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by imf10.hostedemail.com (Postfix) with ESMTP id A9535C0025 for ; Mon, 5 Aug 2024 14:19:26 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=oa3fLywt; spf=pass (imf10.hostedemail.com: domain of elver@google.com designates 209.85.217.53 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722867535; a=rsa-sha256; cv=none; b=uS+vwZcXVgBx35bI+ipCM97X7qUxnclqbmT+YBbSgTSI5nM9dUnlCT4lD4Drz9GbXVaixr plqp4XGou2xs6/emJGaNrgoKi3X8cneRSXPXGc6ZjpE4AmyBh2Yq1MhIYweA5ZB7ET63GP uRyd2vGIEyRdIvvl0rBcSca07KNVmNY= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=oa3fLywt; spf=pass (imf10.hostedemail.com: domain of elver@google.com designates 209.85.217.53 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722867535; 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=4QK3mXKmgaR03PD7D3fidq6cLVoT9CcotLM0Tgs5EgI=; b=w+v4y9C5x8/FRr9FuiTbdo9FT1ZsgHwyVhm/YaMpiTkBdBPzHERsZeC8eExvUtaPgnonvz EHo3hU/cf6gJqmvAD1s50NydHjZUcbXYCZ0mmU7wBYQCRHYOJJB2zMXKLnINtp4Y4R/6Jx E5WdMcl3l8VnsLZNWY/PLCHxGf/fKSw= Received: by mail-vs1-f53.google.com with SMTP id ada2fe7eead31-49296011b52so3075674137.1 for ; Mon, 05 Aug 2024 07:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722867565; x=1723472365; 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=4QK3mXKmgaR03PD7D3fidq6cLVoT9CcotLM0Tgs5EgI=; b=oa3fLywteB2ed8wSh5tNrxBee45kq1xRyJiBfY391EsXjZg9z6TWioVn+lXc/gKf8Y m2a2yPmFwRXnreI4CXj3WiEQ3/a9d1bwdv5ywuTaNJ78EQsluRGI4pcUoYlWKosL7su1 2t1zxdwtqKkRNWlKBqiwxyMuiT73d4AwsCnE862xDYfzQCkNxE889MLk1rMv9Pp4QrPh xgr6TrPxVzsQqpoQ6vlTNEZSQmva6xHCPtdo01erH0COMQT8Icq57ucTBo8jCKTToF16 O6ueHv7bGak1xNY7GcglogpWQmWPiTDO3bFBXkLjt3Quqg0OzMrJWYWpURZCygaijKCg 688Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722867565; x=1723472365; 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=4QK3mXKmgaR03PD7D3fidq6cLVoT9CcotLM0Tgs5EgI=; b=cupGsPySljy0R7Pc4EcSJYayGrwiAkTtYRg8eeqsSgClZHoacWiLzVMyGG1qo6BJiu 8C2rSWYfvAk3Ji1nDy8w5R4qlDyQ/JwiKSWXad/1Ey2aMPi3hNWM24cBBArnOv8A+ppd +lZ7u97ICtKXxhqIT+VG2ScnP9lkK8aueZg64C6l6R9U5ItKDwbEe6E9ZhYZQwylfrNv 0dVGBK8ijXn3R0h4fKqmBNVgI8LDLusBMTrK6Ol1yg2PNhyM7ynl1QRu+02HjYOgPPRG cnjWDFqGJ6nqL8DJOHQhB1bL8dGsfk/49gWghC/JwGhMsW3uwwh+xBK9J2Rpi84B6lnf xgDA== X-Forwarded-Encrypted: i=1; AJvYcCVbHTRYaG7L0bcvncybTKPWvfLDDBOmtqDpBqP/5WXOPktYqXZK22M8zTmKrZIhHvu1MwspNqRQj5v0WYq3JMBxssI= X-Gm-Message-State: AOJu0Ywr7UV6SFvkrL6muCdEprt9dEklSWhzznVzT/RbVZIY6QJCyaIJ LBd+OmUwwzisETP5d6m9KM8WeHaqKKScLFPMMpv5OFai5TmSOHzvYcJrhaX36IuoMkAvEC8+P9j ur4WbhQ6yLBcONO9mS02XEUdeKjxiedVxhs83 X-Google-Smtp-Source: AGHT+IEIAxoyKwH2cF6iDN20dErUcACaqaMc+r5OsWPbnYoCKiUOck0QzjzhmqtTRkGIDONJNod5f1k34JLSyMdHyv4= X-Received: by 2002:a05:6102:38d3:b0:48c:45e3:16e0 with SMTP id ada2fe7eead31-49457ab77eamr8999465137.9.1722867565483; Mon, 05 Aug 2024 07:19:25 -0700 (PDT) MIME-Version: 1.0 References: <20240803133608.2124-1-chenqiwu@xiaomi.com> <20240804034607.GA11291@rlk> <20240805033534.GA15091@rlk> <20240805140601.GA2811@rlk> In-Reply-To: <20240805140601.GA2811@rlk> From: Marco Elver Date: Mon, 5 Aug 2024 16:18:47 +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-Stat-Signature: zj48hr689d7ir18drq4bijyo3nt4dcf5 X-Rspamd-Queue-Id: A9535C0025 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1722867566-385920 X-HE-Meta: U2FsdGVkX1/HvbfQvvC/PhVryxJ0wEC5tBTWgC7xVzO/+kVFFph5lcqfc0bPMnPpTwR8LNK2CcQzMe2FIQlB2QFKoP1GofOE1SyJT2AbYz2Fj/sPx4QCvKjIHgirCxdmiLdl28uvYOAxTLMyfSjwrQsuHD0+OTKLjuzEvTgNfX6H/zSNjIpI4QN0whb2KW/FY6OiKK/nbDskKNwX+W21xTd0y5XhzeTnslAdF2h5yTLEx2NKlGI2+yOKova5Iv32TsrgBqi3MR9KekI/CjjsL29wM9vQv/ZAO9jYov92RWYiJnd9TEG1UhRgosZqtjPmlfezGJgJkodqQMUNhTH5bTpQUH8uZXPy3MoWfweYyJ6MEcLeOOj/tggx6o2pYmq9CYWUnob0ergQjn9RRO3ImRt7dEiQcmTKQGArxIOClm5qnCuQSE5sowi92ExicvmnMA4+dg9Lum7IGlEy6OSg9isdWHwXOIMYIiXjYLUAnr+sS6Xs7VfwbdT1a+RJnXZZIh+PHenWRx5g35uSavJrwU/2yAEmZnol6ru44qX9rfWbYGLtVHDs1R1BTJlEFrxP6DPm1c6k/GBOY62p0zRTrdDPKCPcVynnd19JvnV+3iOGo6rhsRGyo/9qssPcLeF9dHemXaDaMAUf1KzDgE+p2QaMmXMZm9DZT56wRf2LF302c+znFb8bpAaKqhJVcKKzoOYaXhOS9Ek5mLAUTt8m7C0VxS+TUzpoI/VrATkFMC84nKPd4AT3qRZ/fQ4fVPpdE5dSDvQAb7BhMpHO24BHinTo9XeWn4sy//sPk+QBud+T0ExuOdvOpJrNaKqfpSNFiz/2Q8FsugXxwOYdmtapx8JVHUB0GXeISSKWdM6arpxxESmlzSTu4QfGo1Fnwd3VP1DegFuY65oo5sWwjhXowR1f4ciqxBvKgVgS0zWOL92fULSuNZZQPqC8va9dTNBc/dZuPd98bw+6+MWsc/E NAyEPZtf qzt+gMZtv59h87npEH0fqxx6Au/wYdIHIAR3GoGyAr92c0eikGwdJgBrgQPpWMDfbL/47FZCiI09SuPE4ILRo4aSTuzKd7C7NDAR2XJSiCdIe//IKFLzkvz7w39zaCEypgJ0SwWKqD9tuavHErGd3rIGfOTzas0YdOS24bmcvEd/RjWCGwrb0tlDwicSLNYStMl1J X-Bogosity: Ham, tests=bogofilter, spamicity=0.097010, 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 16:06, chenqiwu wrote: > > On Mon, Aug 05, 2024 at 08:50:57AM +0200, Marco Elver wrote: > > > > The "allocated/freed" info is superfluous, as freed objects will have > > a free stack. > > > > Consider a slightly better script vs. just using grep. > Well, I think using grep is eaiser than a script to find leaks by a > large number of alloc tracks. Sure. But a slightly more complex script is a better trade-off vs. impacting _all_ KFENCE users world-wide with slightly less readable error reports. > > /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. > > > How about print meta->state directly to get the object state for its > alloc/free track? > - 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) state %d:\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); > > I'm happy with the "(%lu.%06lus ago)" part alone. > If it's still a not good idea, I will follow your suggestion and resend > it as v2. No, that's just making it more ugly for no reason. It's replicating the state info (just like before) for alloc and free stacks and generally does not add anything useful. See, we are writing code that is deployed on millions of machines, and KFENCE error reports do appear in the wild occasionally. We have to optimize for the common case. Your change might be useful for you, which is a relatively unique usecase. The common use case of KFENCE is to detect memory-safety errors, and good error reports are a major feature of KFENCE. All information is already present in the reports (and /sys/kernel/debug/kfence/objects). I argue that you are able to write a slightly more complex script that simply looks for the free stack right after the allocation stack to determine if an object is live or freed. Maybe doing it in bash won't work so nicely, but a small Python script can easily do that job. Once you have that Python script you might even do further processing, sort things by age, size, etc. etc., and then print whole stack traces. Just grep can't do that. So if you want something useful, you'd have to give up on grep sooner or later.