Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Sat, 18 Nov 2023 17:35:01 +0000
From:   Catalin Marinas <catalin.marinas@arm.com>
To:     Jim Cromie <jim.cromie@gmail.com>
Cc:     linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH 1/2] kmemleak: drop (age <increasing>) from leak record
Message-ID: <ZVj1xcqVRDr7gZYP@arm.com>
References: <20231116224318.124209-1-jim.cromie@gmail.com>
 <20231116224318.124209-2-jim.cromie@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231116224318.124209-2-jim.cromie@gmail.com>
Precedence: bulk

On Thu, Nov 16, 2023 at 03:43:17PM -0700, Jim Cromie wrote:
> Displaying age is pretty, but counter-productive; it changes with
> current-time, so it surrenders idempotency of the output, which breaks
> simple hash-based cataloging of the records by the user.
> 
> The trouble: sequential reads, wo new leaks, get new results:
> 
>   :#> sum /sys/kernel/debug/kmemleak
>   53439    74 /sys/kernel/debug/kmemleak
>   :#> sum /sys/kernel/debug/kmemleak
>   59066    74 /sys/kernel/debug/kmemleak
> 
> and age is why (nothing else changes):
> 
>   :#> grep -v age /sys/kernel/debug/kmemleak | sum
>   58894    67
>   :#> grep -v age /sys/kernel/debug/kmemleak | sum
>   58894    67
> 
> Since jiffies is already printed in the "comm" line, age adds nothing.
> 
> Notably, syzkaller reads kmemleak only for "unreferenced object", and
> won't care about this reform of age-ism.  A few moribund github repos
> mention it, but don't compile.
> 
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>