They're the stack trace of where the allocations occurred, for objects that
are lost. (I won't pretend to understand kmemleak's algorithm for determining
lost objects.)
In this case, I was mounting a server with max_channels=4, which generates
three leak reports (one for the initial session, and two with the same stack
trace, cifs_try_adding_channels -> cifs_ses_add_channel). (With
max_channels=8, I get 7 leak reports)
With
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=16000
CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y
To reproduce:
- mount -t cifs -o multichannel,max_channels=4,... ...
- echo scan > /sys/kernel/debug/kmemleak
or wait long enough for the kmemleak periodic scan to pick it up
- cat /sys/kernel/debug/kmemleak
~Paul
On 2020-07-01 15:35:34 +0200, Aurélien Aptel wrote:
Hi Paul,
These stack traces are where printed when the object is lost right?
Cheers,
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
