On Wed, Oct 02, 2024 at 09:03:56AM -0700, Andi Kleen wrote: > On Wed, Oct 02, 2024 at 02:58:06PM +0200, Greg Kroah-Hartman wrote: > > 6.6-stable review patch. If anyone has any objections, please let me know. > > > > ------------------ > > > > From: Ian Rogers <irogers@xxxxxxxxxx> > > > > [ Upstream commit 599c19397b17d197fc1184bbc950f163a292efc9 ] > > > > The 'struct callchain_cursor_node' has a 'struct map_symbol' whose maps > > and map members are reference counted. Ensure these values use a _get > > routine to increment the reference counts and use map_symbol__exit() to > > release the reference counts. > > > > Do similar for 'struct thread's prev_lbr_cursor, but save the size of > > the prev_lbr_cursor array so that it may be iterated. > > > > Ensure that when stitch_nodes are placed on the free list the > > map_symbols are exited. > > > > Fix resolve_lbr_callchain_sample() by replacing list_replace_init() to > > list_splice_init(), so the whole list is moved and nodes aren't leaked. > > > > A reproduction of the memory leaks is possible with a leak sanitizer > > build in the perf report command of: > > IMHO this doesn't meet stable criteria. It's a theoretical problem > that only causes noise in leak checker outputs, but doesn't actually > affect any real user. The memory is always freed on exit anyways. Ok, now dropped from all queues, thanks for the review. greg k-h
