On Mon, 5 Aug 2024 at 05:35, chenqiwu <qiwuchen55@xxxxxxxxx> 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.
