Re: ipv6 sysctl

Hey netdev guys, Any feedback on this? :-) thanks ani On Tue, Feb 28, 2017 at 11:22 AM, Ani Sinha <a...@arista.com> wrote: > Hi guys, > > Commit a79ca223e029 ('ipv6: fix bad free of addrconf_init_net') > introduced in linux 3.9 tries to fix an issue involving free-ing >

ipv6 sysctl

Hi guys, Commit a79ca223e029 ('ipv6: fix bad free of addrconf_init_net') introduced in linux 3.9 tries to fix an issue involving free-ing statically allocated memory. Additionally, it subtly changes behavior of how certain ipv6 sysctl values are inherited from the default net namespace to the

ip v6 routing behavior difference between linux 3.4 and linux 3.18

Hi guys, I am a little puzzled with a behavior difference I see between linux 3.4 and linux 3.18. Here's my setup where the numbers in hex are ipv6 addresses of the interfaces in parenthesis : fd7a:629f:52a4:fffd::1 (lo0) ∣ ∣ fd7a:629f:52a4:fffe::1 (vlan_dev1) ∣ linux

Re: tbl->lock not taken in neigh_lookup() ?

Hi All: Can I get some insights into this? I am sure I am missing something. thanks ani On Thu, Jan 21, 2016 at 9:05 PM, Ani Sinha <a...@arista.com> wrote: > hi guys > > As per the comment at the top of net/core/neighbor.c we should be > taking this lock even for scanning t

tbl->lock not taken in neigh_lookup() ?

hi guys As per the comment at the top of net/core/neighbor.c we should be taking this lock even for scanning the hash buckets. I do see that this lock is taken in pneigh_lookup() but not in neigh_lookup(). Am i missing something? For the context I am investigating the following crash which

Re: [PATCH 1/1] commit c6825c0976fa7893692e0e43b09740b419b23c09 upstream.

(removed a bunch of people from CC list) On Mon, Oct 26, 2015 at 1:06 PM, Pablo Neira Ayuso wrote: > Then we can review and, if no major concerns, I can submit this to > -stable. Now that Neal has sufficiently tested the patches, is it OK to apply to -stable or do you guys

Re: [PATCH 1/1] commit c6825c0976fa7893692e0e43b09740b419b23c09 upstream.

> On Thu, Oct 29, 2015 at 6:21 PM, Neal P. Murphy > <neal.p.mur...@alum.wpi.edu> wrote: > > On Thu, 29 Oct 2015 17:01:24 -0700 > > Ani Sinha <a...@arista.com> wrote: > > > >> On Wed, Oct 28, 2015 at 11:40 PM, Neal P. Murphy > >> <neal.p.mur

[PATCH -stable 3.4,backport] commit c6825c0976fa7893692e0e43b09740b419b23c09 upstream.

pt+0xe/0x20 <4>[67096.760255] [] sys_sendto+0x139/0x190 <4>[67096.760255] [] ? audit_syscall_entry+0x1d7/0x200 <4>[67096.760255] [] ? __audit_syscall_exit+0x265/0x290 <4>[67096.760255] [] compat_sys_socketcall+0x13f/0x210 <4>[67096.760255] [] ia32_sysret+0x0/

[PATCH -stable 3.4,backport] commit c6825c0976fa7893692e0e43b09740b419b23c09 upstream.

0/0x5 <4>[46267.087676] Code: 91 20 e2 01 75 29 48 89 de 4c 89 f7 e8 56 fa ff ff 85 c0 0f 84 68 fc ff ff 0f b6 4d c6 41 8b 45 00 e9 4d fb ff ff e8 7c 19 e9 e0 <0f> 0b eb fe f6 05 17 91 20 e2 80 74 ce 80 3d 5f 2e 00 00 00 74 <1>[46267.088023] RIP [] nf_nat_setup_info+0x564/0

[PATCH -stable 3.18, backport] ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.

[] compat_sock_common_setsockopt+0x18/0x1f [] compat_SyS_setsockopt+0x1a9/0x1cf [] compat_SyS_socketcall+0x180/0x1e3 [] cstar_dispatch+0x7/0x1e Signed-off-by: Ani Sinha <a...@arista.com> --- net/ipv4/ipmr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/ipv4/ipmr.c

Re: [PATCH -stable 3.18, backport] ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.

On Mon, Nov 2, 2015 at 4:50 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Mon, 2015-11-02 at 16:40 -0800, Ani Sinha wrote: >> [ Upstream commit 44f49dd8b5a606870a1f2 ] > > Please carefully read Documentation/networking/netdev-FAQ.txt > > A: Normally Greg Kr

Re: [PATCH -stable 3.18, backport] ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.

On Mon, Nov 2, 2015 at 4:50 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Mon, 2015-11-02 at 16:40 -0800, Ani Sinha wrote: >> [ Upstream commit 44f49dd8b5a606870a1f2 ] > > Please carefully read Documentation/networking/netdev-FAQ.txt I don't see any recent releases o

[PATCH 1/1] ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.

[] compat_SyS_setsockopt+0x1a9/0x1cf [] compat_SyS_socketcall+0x180/0x1e3 [] cstar_dispatch+0x7/0x1e Signed-off-by: Ani Sinha <a...@arista.com> --- net/ipv4/ipmr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c index 866ee89..8e8203d

Re: [PATCH 1/1] commit c6825c0976fa7893692e0e43b09740b419b23c09 upstream.

On Thu, Oct 29, 2015 at 6:21 PM, Neal P. Murphy <neal.p.mur...@alum.wpi.edu> wrote: > On Thu, 29 Oct 2015 17:01:24 -0700 > Ani Sinha <a...@arista.com> wrote: > >> On Wed, Oct 28, 2015 at 11:40 PM, Neal P. Murphy >> <neal.p.mur...@alum.wpi.edu> wrote:

Re: kernel BUG in ipmr_queue_xmit()

On Fri, Oct 30, 2015 at 4:00 AM, Eric Dumazet wrote: > On Fri, 2015-10-30 at 11:48 +0100, Florian Westphal wrote: >> Hannes Frederic Sowa wrote: >> > > > > @@ -936,7 +936,9 @@ static void ipmr_cache_resolve(struct net *net, >> > > > > struct

Re: kernel BUG in ipmr_queue_xmit()

On Fri, Oct 30, 2015 at 12:12 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Fri, 2015-10-30 at 10:47 -0700, Ani Sinha wrote: > >> for 32 bit archs, it does in SNMP_ADD_STATS64_USER() > > Sure. But x86 these days is 64bit, at 99 % maybe. > > We do not make ch

Re: [PATCH 1/1] commit c6825c0976fa7893692e0e43b09740b419b23c09 upstream.

ilter.org> wrote: >> >> > Hi, >> > >> > On Mon, Oct 26, 2015 at 11:55:39AM -0700, Ani Sinha wrote: >> > > netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get >> > >> > Please, no need to Cc everyone here. Please, submit your

[PATCH 1/1] commit c6825c0976fa7893692e0e43b09740b419b23c09 upstream.

90 Cc: Eric Dumazet <eric.duma...@gmail.com> Cc: Florian Westphal <f...@strlen.de> Cc: Pablo Neira Ayuso <pa...@netfilter.org> Cc: Patrick McHardy <ka...@trash.net> Cc: Jozsef Kadlecsik <kad...@blackhole.kfki.hu> Cc: "David S. Miller" <da...@davemlo

[PATCH 1/1] commit c6825c0976fa7893692e0e43b09740b419b23c09 upstream.

90 Cc: Eric Dumazet <eric.duma...@gmail.com> Cc: Florian Westphal <f...@strlen.de> Cc: Pablo Neira Ayuso <pa...@netfilter.org> Cc: Patrick McHardy <ka...@trash.net> Cc: Jozsef Kadlecsik <kad...@blackhole.kfki.hu> Cc: "David S. Miller" <da...@davemlo

[PATCH 1/1] commit e53376bef2cd97d3e3f61fdc677fb8da7d03d0da upstream.

ave reused the original title for the RFC patch that Andrey posted and most of the original patch description. Cc: Eric Dumazet <eduma...@google.com> Cc: Andrew Vagin <ava...@parallels.com> Cc: Florian Westphal <f...@strlen.de> Cc: Zefan Li <lize...@huawei.com> Signed-off-by

Re: [PATCH 1/1] commit c6825c0976fa7893692e0e43b09740b419b23c09 upstream.

Please refer to the thread "linux 3.4.43 : kernel crash at __nf_conntrack_confirm" on netdev for context. thanks On Sat, Oct 24, 2015 at 11:27 AM, Ani Sinha <a...@arista.com> wrote: > netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get > > Lets

Re: [PATCH 1/1] commit e53376bef2cd97d3e3f61fdc677fb8da7d03d0da upstream.

Please refer to the thread "linux 3.4.43 : kernel crash at __nf_conntrack_confirm" on netdev for context. thanks On Sat, Oct 24, 2015 at 10:27 AM, Ani Sinha <a...@arista.com> wrote: > netfilter: nf_conntrack: don't release a conntrack with non-zero > refcnt > > Wi

Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm

On Sun, Oct 18, 2015 at 1:07 AM, Florian Westphal <f...@strlen.de> wrote: > Ani Sinha <a...@arista.com> wrote: >> Coming back to this crash, I see something interesting in the >> conntrack code in linux 3.4.109 (a supported kernel version). I see >> that the hash

Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm

On Wed, Oct 21, 2015 at 2:19 PM, Florian Westphal <f...@strlen.de> wrote: > Ani Sinha <a...@arista.com> wrote: >> >> > commit c6825c0976fa7893692e0e43b09740b419b23c09 >> >> > Author: Andrey Vagin <ava...@openvz.org> >> >>

Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm

On Sun, Oct 18, 2015 at 2:40 PM, Florian Westphal <f...@strlen.de> wrote: > Ani Sinha <a...@arista.com> wrote: >> Indeed. So it seems to me that we have run into one another such case. >> In patch c6825c0976fa7893692, I see we have added an additional check (along >&

Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm

On Mon, Oct 19, 2015 at 1:33 PM, Florian Westphal <f...@strlen.de> wrote: > Ani Sinha <a...@arista.com> wrote: >> On Sun, Oct 18, 2015 at 2:40 PM, Florian Westphal <f...@strlen.de> wrote: >> > Ani Sinha <a...@arista.com> wrote: >> >> Indee

Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm

> > On Sun, Oct 18, 2015 at 1:07 AM, Florian Westphal <f...@strlen.de> wrote: > > Ani Sinha <a...@arista.com> wrote: > >> Coming back to this crash, I see something interesting in the > >> conntrack code in linux 3.4.109 (a supported kernel version). I

Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm

the one I described can result in the crash I sent below. thanks ani On Wed, Oct 7, 2015 at 12:57 PM, Ani Sinha <a...@arista.com> wrote: > Hi guys : > > We encountered a kernel crash on one of our boxes running 3.4.43 > kernel in the conntrack code. We are using dnsmasq as a proxy

linux 3.4.43 : kernel crash at __nf_conntrack_confirm

Hi guys : We encountered a kernel crash on one of our boxes running 3.4.43 kernel in the conntrack code. We are using dnsmasq as a proxy to relay our dns requests to the real dns server. We verified that the conntrack tables were not full. running conntrack -L around the time of the crash showed

iproute2 compatibility

Hi Stephen : I was looking around but could not find clear evidence that a later version of iproute2 is compatible with an older kernel. Specifically, we are wondering if iproute2 v 3.6 is compatible with linux kernel 3.4. Highly appreciate any pointers on this. thanks ani -- To unsubscribe from

Re: iproute2 compatibility

On Thu, Oct 1, 2015 at 1:48 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2015-10-01 at 13:06 -0700, Ani Sinha wrote: >> Hi Stephen : >> >> I was looking around but could not find clear evidence that a later >> version of iproute2 is compatible w

Re: list of all network namespaces

On Thu, Sep 17, 2015 at 2:51 AM, Rosen, Rami wrote: > Network namespaces which were created by other ways (like userspace > applications > using the clone() system call) will *not* be reflected by neither of them. Will there be any interest if I cook up a kernel patch

list of all network namespaces

Hi guys just a stupid question. Is it possible to get a list of all active network namespaces in the kernel through /proc or some other interface? thanks ani -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo