Re: [linux-yocto] [PATCH] netfilter: Fix kmemleak false positive reports
On 2018/10/25 18:29, Bruce Ashfield wrote: > On 10/23/18 6:33 AM, zhe...@windriver.com wrote: >> From: He Zhe >> >> unreferenced object 0x9643edb89900 (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: >> [<70d5b185>] kmem_cache_alloc+0x146/0x200 >> [<07a27faa>] __nf_conntrack_alloc.isra.13+0x4d/0x170 >> [nf_conntrack] >> [] init_conntrack+0x6a/0x2f0 [nf_conntrack] >> [<3d38809f>] nf_conntrack_in+0x2c5/0x360 [nf_conntrack] >> [<1fe154e3>] ipv4_conntrack_local+0x5d/0x70 [nf_conntrack_ipv4] >> [<27adadb2>] nf_hook_slow+0x48/0xd0 >> [<9893511f>] __ip_local_out+0xbd/0xf0 >> [ ] ip_local_out+0x1c/0x50 >> [<995e2f37>] ip_send_skb+0x19/0x40 >> [<3d95f220>] udp_send_skb.isra.5+0x157/0x360 >> [ ] udp_sendmsg+0x9d8/0xc10 >> [<3bef56ec>] inet_sendmsg+0x3e/0xf0 >> [<8d23e405>] sock_sendmsg+0x1d/0x30 >> [<8c297097>] ___sys_sendmsg+0x108/0x2b0 >> [ ] __sys_sendmmsg+0xba/0x1c0 >> [ ] __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 >> --- >> 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 >> #include >> #include >> +#include >> #include >> #include >> @@ -1138,6 +1139,8 @@ __nf_conntrack_alloc(struct net *net, >> if (ct == NULL) >> goto out; >> + kmemleak_not_leak(ct); >> + >> spin_lock_init(>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
Re: [linux-yocto] [PATCH] ipv4: net namespace does not inherit network configurations
On 10/24/18 2:27 AM, zhe...@windriver.com wrote:
From: He Zhe
patch from https://lkml.org/lkml/2014/7/29/119
Did this never make the mainline kernel ?
We either need an upstream git commit hash, or an explanation of
why it didn't make mainline. I haven't read the link you provided,
but I shouldn't have to click on anything in a commit message :D
Bruce
Ipv4 net namespace requires a similar logic change as commit a79ca223e029
[ipv6: fix bad free of addrconf_init_net] introduces for newer kernels.
Since a net namespace is independent to another. That is, there
is no any relationship between the net namespaces. So a new net
namespace should not inherit network configurations from another
net namespace including the host.
CC: Hong Zhiguo
CC: David S. Miller
Signed-off-by: Zhu Yanjun
Signed-off-by: yzhu1
Signed-off-by: He Zhe
---
This is for linux-yocto-dev, linux-yocto master and 4.18 branches.
net/ipv4/devinet.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index ea4bd8a..f69b2dd 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -2412,28 +2412,23 @@ static __net_init int devinet_init_net(struct net *net)
#endif
err = -ENOMEM;
- all = _devconf;
- dflt = _devconf_dflt;
+ all = kmemdup(_devconf, sizeof(ipv4_devconf), GFP_KERNEL);
+ if (all == NULL)
+ goto err_alloc_all;
- if (!net_eq(net, _net)) {
- all = kmemdup(all, sizeof(ipv4_devconf), GFP_KERNEL);
- if (!all)
- goto err_alloc_all;
-
- dflt = kmemdup(dflt, sizeof(ipv4_devconf_dflt), GFP_KERNEL);
- if (!dflt)
- goto err_alloc_dflt;
+ dflt = kmemdup(_devconf_dflt, sizeof(ipv4_devconf_dflt),
GFP_KERNEL);
+ if (dflt == NULL)
+ goto err_alloc_dflt;
#ifdef CONFIG_SYSCTL
- tbl = kmemdup(tbl, sizeof(ctl_forward_entry), GFP_KERNEL);
- if (!tbl)
- goto err_alloc_ctl;
+ tbl = kmemdup(tbl, sizeof(ctl_forward_entry), GFP_KERNEL);
+ if (tbl == NULL)
+ goto err_alloc_ctl;
- tbl[0].data = >data[IPV4_DEVCONF_FORWARDING - 1];
- tbl[0].extra1 = all;
- tbl[0].extra2 = net;
+ tbl[0].data = >data[IPV4_DEVCONF_FORWARDING - 1];
+ tbl[0].extra1 = all;
+ tbl[0].extra2 = net;
#endif
- }
#ifdef CONFIG_SYSCTL
err = __devinet_sysctl_register(net, "all", NETCONFA_IFINDEX_ALL, all);
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [yocto-4.14][PATCH] sound.cfg: enable SND_SOC_INTEL_SKYLAKE explicitly
On 10/23/18 2:28 AM, Anuj Mittal wrote: This helps kernels that might have the sound/soc kconfig changes backported to 4.14 [1]. Looks good. As I mentioned in other email, Due to travel, I haven't gotten to it yet. But it will be merged by Monday. Bruce This is selected by default by SND_SOC_INTEL_SKL_* configs in 4.14 that are enabled to be built already in sound.cfg, so this will not result in any change in behaviour. [1] https://github.com/torvalds/linux/commit/f6a118a800e35af2c63f90cbcc23093f4b53b3a2 Signed-off-by: Anuj Mittal --- cfg/sound.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/cfg/sound.cfg b/cfg/sound.cfg index e8b2a921..51568d4d 100644 --- a/cfg/sound.cfg +++ b/cfg/sound.cfg @@ -59,6 +59,7 @@ CONFIG_SND_SOC_INTEL_CHT_BSW_RT5645_MACH=m CONFIG_SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH=m CONFIG_SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH=m CONFIG_SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH=m +CONFIG_SND_SOC_INTEL_SKYLAKE=m CONFIG_SND_SOC_AC97_CODEC=m CONFIG_SND_SOC_AK4104=m CONFIG_SND_SOC_AK4554=m -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] netfilter: Fix kmemleak false positive reports
On 10/23/18 6:33 AM, zhe...@windriver.com wrote: From: He Zhe unreferenced object 0x9643edb89900 (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: [<70d5b185>] kmem_cache_alloc+0x146/0x200 [<07a27faa>] __nf_conntrack_alloc.isra.13+0x4d/0x170 [nf_conntrack] [] init_conntrack+0x6a/0x2f0 [nf_conntrack] [<3d38809f>] nf_conntrack_in+0x2c5/0x360 [nf_conntrack] [<1fe154e3>] ipv4_conntrack_local+0x5d/0x70 [nf_conntrack_ipv4] [<27adadb2>] nf_hook_slow+0x48/0xd0 [<9893511f>] __ip_local_out+0xbd/0xf0 [ ] ip_local_out+0x1c/0x50 [<995e2f37>] ip_send_skb+0x19/0x40 [<3d95f220>] udp_send_skb.isra.5+0x157/0x360 [ ] udp_sendmsg+0x9d8/0xc10 [<3bef56ec>] inet_sendmsg+0x3e/0xf0 [<8d23e405>] sock_sendmsg+0x1d/0x30 [<8c297097>] ___sys_sendmsg+0x108/0x2b0 [ ] __sys_sendmmsg+0xba/0x1c0 [ ] __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 Bruce Signed-off-by: He Zhe --- 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 #include #include +#include #include #include @@ -1138,6 +1139,8 @@ __nf_conntrack_alloc(struct net *net, if (ct == NULL) goto out; + kmemleak_not_leak(ct); + spin_lock_init(>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
Re: [linux-yocto] [PATCH 0/1] config cleanup
On 10/22/18 11:28 PM, Anuj Mittal wrote: Hi Bruce, Can you please merge this in 4.18, 4.19 and master? Thanks! The patch looks fine. Due to travel, I haven't gotten to it yet. But it will be merged by Monday. Bruce Anuj Mittal (1): sound.cfg: enable SND_SOC_INTEL_SKYLAKE cfg/sound.cfg | 1 + 1 file changed, 1 insertion(+) -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
