On Tue, Sep 18, 2018 at 04:47:31PM +0000, Mark Bloch wrote: > > > On 9/17/2018 2:06 PM, Bart Van Assche wrote: > > On 9/17/18 11:47 AM, Mark Bloch wrote: > >> Can you please try the patch below? > >> Also, you should probably use rc4 is it contains a fix from Parav: > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/infiniband/core/uverbs_main.c?id=08e74be103051861eb2c1ee52a2dcf119cde264f > >> > >> commit 00788797517e542db51a5d9c8defeacc357e9967 (HEAD -> master) > >> Author: Mark Bloch <markb@xxxxxxxxxxxx> > >> Date: Mon Sep 17 18:12:40 2018 +0000 > >> > >> IB/uverbs: Free uapi on destroy > >> > >> Make sure we free uapi once we clean the radix tree. > >> > >> Fixes: 9ed3e5f44772 ("IB/uverbs: Build the specs into a radix tree at runtime") > >> Signed-off-by: Mark Bloch <markb@xxxxxxxxxxxx> > >> > >> diff --git a/drivers/infiniband/core/uverbs_uapi.c b/drivers/infiniband/core/uverbs_uapi.c > >> index 73ea6f0db88f..be854628a7c6 100644 > >> +++ b/drivers/infiniband/core/uverbs_uapi.c > >> @@ -248,6 +248,7 @@ void uverbs_destroy_api(struct uverbs_api *uapi) > >> kfree(rcu_dereference_protected(*slot, true)); > >> radix_tree_iter_delete(&uapi->radix, &iter, slot); > >> } > >> + kfree(uapi); > >> } > > > > Hello Mark, > > > > Thanks for the patch. With the above patch applied on top of rc4 the number of leaks that is reported is lower but I still see two leak reports for ib_uverbs_add_one: > > Well that's a start :) > I'll push it internally for regression/test/verification, Leon will send it to the list. > > > > > unreferenced object 0xffff8800d6b26380 (size 96): > > comm "modprobe", pid 972, jiffies 4294942469 (age 610.200s) > > hex dump (first 32 bytes): > > 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... > > ff ff ff ff ff ff ff ff a0 04 f1 a0 ff ff ff ff ................ > > backtrace: > > [<00000000f3883524>] ib_uverbs_add_one+0x231/0x470 [ib_uverbs] > > [<0000000014e73c3d>] ib_register_client+0x5b/0x100 [ib_core] > > [<00000000ea5b6564>] 0xffffffffa0e680e0 > > [<000000008104a168>] do_one_initcall+0x93/0x37c > > [<00000000d14612bc>] do_init_module+0xde/0x334 > > [<0000000084e6455a>] load_module+0x3b30/0x46c0 > > [<00000000932b71c1>] __do_sys_finit_module+0x176/0x1a0 > > [<000000003d2bfbc8>] do_syscall_64+0x72/0x230 > > [<0000000047808356>] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > [<000000008c0ba35d>] 0xffffffffffffffff > > unreferenced object 0xffff880034dc5580 (size 96): > > comm "modprobe", pid 972, jiffies 4294942470 (age 610.190s) > > hex dump (first 32 bytes): > > 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... > > ff ff ff ff ff ff ff ff a0 04 f1 a0 ff ff ff ff ................ > > backtrace: > > [<00000000f3883524>] ib_uverbs_add_one+0x231/0x470 [ib_uverbs] > > [<0000000014e73c3d>] ib_register_client+0x5b/0x100 [ib_core] > > [<00000000ea5b6564>] 0xffffffffa0e680e0 > > [<000000008104a168>] do_one_initcall+0x93/0x37c > > [<00000000d14612bc>] do_init_module+0xde/0x334 > > [<0000000084e6455a>] load_module+0x3b30/0x46c0 > > [<00000000932b71c1>] __do_sys_finit_module+0x176/0x1a0 > > [<000000003d2bfbc8>] do_syscall_64+0x72/0x230 > > [<0000000047808356>] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > [<000000008c0ba35d>] 0xffffffffffffffff > > > > I had to compile kmemleak and test as I couldn't see anything in the code, and > I got this: > > unreferenced object 0xffff8d59df14bd98 (size 576): > comm "sh", pid 11372, jiffies 4296844401 (age 475.632s) > hex dump (first 32 bytes): > 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > e0 e5 45 c0 ff ff ff ff b0 bd 14 df 59 8d ff ff ..E.........Y... > backtrace: > [<00000000cd71a38b>] kmem_cache_alloc+0x17f/0x2e0 > [<000000002c6b8c3a>] radix_tree_node_alloc.constprop.17+0x87/0xe0 > [<0000000035b66202>] radix_tree_extend+0xcf/0x180 > [<000000005a1893d7>] idr_get_free+0x2c7/0x330 > [<000000009ee48494>] idr_alloc_u32+0x76/0xe0 > [<00000000b46492c9>] idr_alloc_cyclic+0x5e/0xc0 > [<000000005901fe00>] 0xffffffffc0447c81 > [<00000000cbf604ac>] 0xffffffffc044b375 > [<00000000339966c1>] 0xffffffffc0447061 > [<00000000c466b8e1>] 0xffffffffc04394a5 > [<0000000019abc1ca>] ib_device_get_by_index+0xc/0x90 [ib_core] > [<00000000aebadd3a>] ib_ud_header_pack+0x3f/0x1d0 [ib_core] > [<00000000104c9a7d>] enum_netdev_ipv6_ips+0x2d8/0x340 [ib_core] > [<000000007384a0a9>] ib_mr_pool_put+0x3e/0x60 [ib_core] > [<00000000ff316bf7>] param_attr_store+0x69/0xd0 > [<000000004b16a918>] module_attr_store+0x20/0x30 > > > and I see this size (576) for different modules and different backtraces, > but the issue you reported I can't hit. These backtraces are really misleading, and so are Bart's.. Make sure to use CONFIG_UNWINDER_FRAME_POINTER=y The ORC unwinder is not very good. Hopefully that will clarify what is happening.. Jason
