Description of problem: Running lvm2 test suite 'make check_local T=lvconvert-raid.sh' leaks ~336 4K pages reported by kmemleak. unreferenced object 0xffff8f4311e9c000 (size 4096): comm "lvm", pid 19333, jiffies 4295263268 (age 528.265s) hex dump (first 32 bytes): 02 80 02 80 02 80 02 80 02 80 02 80 02 80 02 80 ................ 02 80 02 80 02 80 02 80 02 80 02 80 02 80 02 80 ................ backtrace: [<ffffffffa69471ca>] kmemleak_alloc+0x4a/0xa0 [<ffffffffa628c10e>] kmem_cache_alloc_trace+0x14e/0x2e0 [<ffffffffa676cfec>] bitmap_checkpage+0x7c/0x110 [<ffffffffa676d0c5>] bitmap_get_counter+0x45/0xd0 [<ffffffffa676d6b3>] bitmap_set_memory_bits+0x43/0xe0 [<ffffffffa676e41c>] bitmap_init_from_disk+0x23c/0x530 [<ffffffffa676f1ae>] bitmap_load+0xbe/0x160 [<ffffffffc04c47d3>] raid_preresume+0x203/0x2f0 [dm_raid] [<ffffffffa677762f>] dm_table_resume_targets+0x4f/0xe0 [<ffffffffa6774b52>] dm_resume+0x122/0x140 [<ffffffffa6779b9f>] dev_suspend+0x18f/0x290 [<ffffffffa677a3a7>] ctl_ioctl+0x287/0x560 [<ffffffffa677a693>] dm_ctl_ioctl+0x13/0x20 [<ffffffffa62d6b46>] do_vfs_ioctl+0xa6/0x750 [<ffffffffa62d7269>] SyS_ioctl+0x79/0x90 [<ffffffffa6956d41>] entry_SYSCALL_64_fastpath+0x1f/0xc2 Version-Release number of selected component (if applicable): kernel 4.10-rcX dm raid target 1.9.0/1 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Actually 'make check_local T=lvcreate-large-raid.sh' is the one which surely triggers problem.
The resoning seems to be that bitmap_free() does not free hijacked bitmap pages: "(if (bp[k].map && !bp[k].hijacked) kfree(bp[k].map);" Currrent theory is, that bp[k].hijacked is not being reset properly before the bitmap is being destroyed. Hijackinga bitmap page becomes necessary under low memory conditions _but_ freeing it up on destroy must happen or leak.
Instrumented and tested: never hit a bk[k].hijacked -> theory's wrong.
Thinking twice, the leaks are being detected on initial bitmap_load() when kzalloc() is called from bitmap_checkpage() referencing the result via an auto ptr variable which can be conditionally used to free the allocation or set the repective slots reference in the bitmap page map array. I don't see where the any leakage is in that code path yet.
I believe the bug is related to resize of bitmap whet the content of old bitmap map states were not released. With this patch I get these leak fixd: diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c index d2121637b4ab..58ee21027709 100644 --- a/drivers/md/bitmap.c +++ b/drivers/md/bitmap.c @@ -2152,6 +2152,7 @@ int bitmap_resize(struct bitmap *bitmap, sector_t blocks, for (k = 0; k < page; k++) { kfree(new_bp[k].map); } + kfree(new_bp); /* restore some fields from old_counts */ bitmap->counts.bp = old_counts.bp; @@ -2202,6 +2203,14 @@ int bitmap_resize(struct bitmap *bitmap, sector_t blocks, block += old_blocks; } + if (bitmap->counts.bp != old_counts.bp) { + unsigned long k; + for (k = 0; k < old_counts.pages; k++) + if (!old_counts.bp[k].hijacked) + kfree(old_counts.bp[k].map); + kfree(old_counts.bp); + } + if (!init) { int i; while (block < (chunks << chunkshift)) {
MD upstream kernel commit 0868b99c214a3d55486c700de7c3f770b7243e7c needs to be backported to rhel7 kernel.