search

dolohow / uksm

Ultra Kernel Samepage Merging
242 stars 35 forks source link

kmemleak gets lots of false positives when using UKMS #63

Open lwfinger opened 4 years ago

lwfinger commented 4 years ago

Last week I was helping a user of UKSM that was having failures of swiotbl entries. To see if it would help, he turned on kmemleak. Immediately, we got a lot of entries with the following back-trace:

[<00000000df775e69>] get_next_rmap_item+0x129b/0x1600 [<00000000c3ada4e5>] scan_vma_one_page+0x40/0xf0 [<000000009a1b1eb3>] uksm_do_scan+0x164/0x2040 [<000000009ad9d2b0>] uksm_scan_thread+0x18e/0x1d0 [<00000000b85a4745>] kthread+0x11c/0x160 [<0000000075d8016e>] ret_from_fork+0x35/0x40

These point to the alllocation of rmap_item in scan_vma_one_page(). When I first analyzed the code, I thought I saw where this memory was being freed, but I cannot repeat the analysis. I do not see any increase in memory usage with UKMS installed, thus I believe that these are false positive results from kmemleak. If that is true, kmemleak can be silenced with the attached patch:

patch_uksm.txt

yavincl commented 4 years ago

Perhaps this is not a false positive, as after removing UKSM from my patchset the memory-slowly-filling-up-over-time issue completely disappeared. This is a difficult to diagnose issue I am no longer interested in going after, since removing UKSM also got rid of my memory scarcity problems. There is also a possibility it is related to something, anything different in my setup that may be causing uksm to leak memory.