On Thu, 2018-01-11 at 01:04 -0500, Douglas Gilbert wrote: > Monitoring that program with 'free' from another terminal I see > about 2.5 GBytes of ram "swallowed" almost immediately when the test > program runs. When the program exits (about 50 seconds later) as far > as I can see all that ram is given back. Hello Doug, There is probably something that's leaking memory in one of the functions in the reported call stack. kmemleak reports the following in my tests (I haven't had the time yet to analyze this further): unreferenced object 0xffff880363c09088 (size 192): comm "multipath", pid 20088, jiffies 4295034706 (age 6544.980s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 20 00 00 00 12 01 00 00 00 00 00 00 .... ........... backtrace: [<ffffffff81659e1a>] kmemleak_alloc+0x4a/0xa0 [<ffffffff811f51fe>] __kmalloc+0x16e/0x320 [<ffffffff812e4848>] bio_alloc_bioset+0x198/0x1f0 [<ffffffff812e51b9>] bio_map_user_iov+0x129/0x3f0 [<ffffffff812f5863>] blk_rq_map_user_iov+0x123/0x210 [<ffffffff812f5a02>] blk_rq_map_user+0x52/0x60 [<ffffffff8130b7b5>] sg_io+0x385/0x3c0 [<ffffffff8130bad3>] scsi_cmd_ioctl+0x2e3/0x450 [<ffffffff8130bc82>] scsi_cmd_blk_ioctl+0x42/0x50 [<ffffffff8148d835>] sd_ioctl+0x85/0x110 [<ffffffff81302bfb>] blkdev_ioctl+0x4db/0x970 [<ffffffff812660fd>] block_ioctl+0x3d/0x50 [<ffffffff812348d4>] do_vfs_ioctl+0x94/0x670 [<ffffffff81234ef1>] SyS_ioctl+0x41/0x70 [<ffffffff81001e5c>] do_syscall_64+0x5c/0x110 [<ffffffff81667564>] return_from_SYSCALL_64+0x0/0x7a Bart.
