On 2018/10/25 18:29, Bruce Ashfield wrote: > On 10/23/18 6:33 AM, zhe...@windriver.com wrote: >> From: He Zhe <zhe...@windriver.com> >> >> unreferenced object 0xffff9643edb89900 (size 256): >> comm "sd-resolve", pid 220, jiffies 4295016710 (age 208.256s) >> hex dump (first 32 bytes): >> 01 00 00 00 00 00 00 00 03 00 74 f3 ba b1 b6 b5 ..........t..... >> 65 3e 00 00 00 00 00 00 90 f9 a0 ed 43 96 ff ff e>..........C... >> backtrace: >> [<0000000070d5b185>] kmem_cache_alloc+0x146/0x200 >> [<0000000007a27faa>] __nf_conntrack_alloc.isra.13+0x4d/0x170 >> [nf_conntrack] >> [<00000000ecc5b0ec>] init_conntrack+0x6a/0x2f0 [nf_conntrack] >> [<000000003d38809f>] nf_conntrack_in+0x2c5/0x360 [nf_conntrack] >> [<000000001fe154e3>] ipv4_conntrack_local+0x5d/0x70 [nf_conntrack_ipv4] >> [<0000000027adadb2>] nf_hook_slow+0x48/0xd0 >> [<000000009893511f>] __ip_local_out+0xbd/0xf0 >> [<00000000d68cbd2f>] ip_local_out+0x1c/0x50 >> [<00000000995e2f37>] ip_send_skb+0x19/0x40 >> [<000000003d95f220>] udp_send_skb.isra.5+0x157/0x360 >> [<00000000ebc25968>] udp_sendmsg+0x9d8/0xc10 >> [<000000003bef56ec>] inet_sendmsg+0x3e/0xf0 >> [<000000008d23e405>] sock_sendmsg+0x1d/0x30 >> [<000000008c297097>] ___sys_sendmsg+0x108/0x2b0 >> [<00000000f15a806c>] __sys_sendmmsg+0xba/0x1c0 >> [<00000000e195d2cf>] __x64_sys_sendmmsg+0x24/0x30 >> >> In __nf_conntrack_confirm, object ct can be referenced to by the stack >> variable >> ct and the members of ct->tuplehash. kmemleak needs at least one of them to >> find >> the ct object during scan. >> >> When the ct object is moved from the unconfirmed hlist to the confirmed >> hlist. >> kmemleak cannot see ct object if things happen in the following order and >> thus >> give the above false positive report. >> 1) ct object is removed from unconfirmed hlist. >> 2) kmemleak scans data/bss sections. >> 3) ct object is added to confirmed hlist and ct is destroyed as the function >> returns. >> 4) kmemleak scans task stacks. >> >> This patch marks the ct object as not a leak. > > Has this also been submitted upstream ? > > Due to travel, I haven't gotten to it yet. But if it has been submitted > upstream, I can get it merged by Monday
This has been submitted to lkml but has not got any attention. Mark and I still are working on it to pinpoint the bad code. Zhe > > Bruce > >> >> Signed-off-by: He Zhe <zhe...@windriver.com> >> --- >> This is only for v4.18 >> >> net/netfilter/nf_conntrack_core.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/net/netfilter/nf_conntrack_core.c >> b/net/netfilter/nf_conntrack_core.c >> index 3d52804..9b554c7 100644 >> --- a/net/netfilter/nf_conntrack_core.c >> +++ b/net/netfilter/nf_conntrack_core.c >> @@ -35,6 +35,7 @@ >> #include <linux/mm.h> >> #include <linux/nsproxy.h> >> #include <linux/rculist_nulls.h> >> +#include <linux/kmemleak.h> >> #include <net/netfilter/nf_conntrack.h> >> #include <net/netfilter/nf_conntrack_l3proto.h> >> @@ -1138,6 +1139,8 @@ __nf_conntrack_alloc(struct net *net, >> if (ct == NULL) >> goto out; >> + kmemleak_not_leak(ct); >> + >> spin_lock_init(&ct->lock); >> ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple = *orig; >> ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.pprev = NULL; >> > > -- _______________________________________________ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto