Re: [RFC PATCH net] net/core: don't increment rx_dropped on inactive slaves

Fri, Jan 22, 2016 at 09:59:12PM CET, jay.vosbu...@canonical.com wrote: >Jarod Wilson wrote: > >>The network core tries to keep track of dropped packets, but some packets >>you wouldn't really call dropped, so much as intentionally ignored, under >>certain circumstances. One such

[PATCH] net: dsa: fix mv88e6xxx switches

Since commit 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del ops"), the Marvell 88E6xxx switch has been unable to pass traffic between ports - any received traffic is discarded by the switch. Taking a port out of bridge mode and configuring a vlan on it also the port to start passing

[PATCH] ipv4+ipv6: Make INET*_ESP select CRYPTO_ECHAINIV

The ESP algorithms using CBC mode require echainiv. Hence INET*_ESP have to select CRYPTO_ECHAINIV in order to work properly. This solves the issues caused by a misconfiguration as described in [1]. The original approach, patching crypto/Kconfig was turned down by Herbert Xu [2]. [1]

Re: [RFC PATCH net] net/core: don't increment rx_dropped on inactive slaves

Fri, Jan 22, 2016 at 08:11:22PM CET, ja...@redhat.com wrote: >The network core tries to keep track of dropped packets, but some packets >you wouldn't really call dropped, so much as intentionally ignored, under >certain circumstances. One such case is that of bonding and team device >slaves that

Re: [RFC PATCH net] net/core: don't increment rx_dropped on inactive slaves

On Fri, 2016-01-22 at 14:11 -0500, Jarod Wilson wrote: > --- > net/core/dev.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/core/dev.c b/net/core/dev.c > index 8cba3d8..1354c7b 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -4153,8 +4153,11 @@ ncls: >

Re: struct pid memory leak

Hi Eric, Dmitry, On Fri, Jan 22, 2016 at 08:50:01AM -0800, Eric Dumazet wrote: > CC netdev, as it looks some af_unix issue ... > > On Fri, 2016-01-22 at 16:08 +0100, Dmitry Vyukov wrote: > > Hello, > > > > The following program causes struct pid memory leak: > > > > // autogenerated by

Re: [PATCH] net: dsa: fix mv88e6xxx switches

On Sat, Jan 23, 2016 at 07:48:57PM +, Russell King - ARM Linux wrote: > On Sat, Jan 23, 2016 at 08:37:05PM +0100, Andrew Lunn wrote: > > I'm testing on a 6172. But 6172 and 6176 are both in the same family > > 6352, and share the same driver. > > Hmm, can't be that then. > > > So you

Re: [Xen-devel] [PATCH 1/3] xen-netback: fix license ident used in MODULE_LICENSE

On Fri, Jan 22, 2016 at 08:25:21PM +, One Thousand Gnomes wrote: > > The fact what include/linux/license.h:license_is_gpl_compatible includes > > "Dual MIT/GPL" as an option seems to suggest that it is enough of a thing > > to be validly used as the contents of a MODULE_LICENSE() thing. > >

Re: [PATCH] net: dsa: fix mv88e6xxx switches

On Sat, Jan 23, 2016 at 08:37:05PM +0100, Andrew Lunn wrote: > I'm testing on a 6172. But 6172 and 6176 are both in the same family > 6352, and share the same driver. Hmm, can't be that then. > So you initially have lan1 in an bridge. I don't. Okay, I've disabled br0 in the debian

Re: [RFC PATCH net] net/core: don't increment rx_dropped on inactive slaves

On Fri, Jan 22, 2016 at 02:11:22PM -0500, Jarod Wilson wrote: > The network core tries to keep track of dropped packets, but some packets > you wouldn't really call dropped, so much as intentionally ignored, under > certain circumstances. One such case is that of bonding and team device > slaves

Re: net: GPF in netlink_getsockbyportid

On 01/23/2016 08:25 PM, Florian Westphal wrote: Dmitry Vyukov wrote: [ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ] The following program causes GPF in netlink_getsockbyportid: // autogenerated by syzkaller (http://github.com/google/syzkaller) #include

Re: struct pid memory leak

On Sat, Jan 23, 2016 at 07:14:33PM +0100, Dmitry Vyukov wrote: > I've attached my .config. > Also run this program in a parallel loop. I think it's leaking not > every time, probably some race is involved. Thank you. Just in order to confirm, am I supposed to see the messages you quoted in dmesg

Re: [PATCH] net: dsa: fix mv88e6xxx switches

On Sat, Jan 23, 2016 at 07:06:22PM +, Russell King - ARM Linux wrote: > On Sat, Jan 23, 2016 at 07:15:26PM +0100, Andrew Lunn wrote: > > Thanks for digging into this. > > I hope you saw v2, which is functionally identical. No, not yet. I will go look for it. > > I think this is a step

Re: struct pid memory leak

On Sat, Jan 23, 2016 at 10:46 AM, Dmitry Vyukov wrote: > On Sat, Jan 23, 2016 at 7:40 PM, Willy Tarreau wrote: >> On Sat, Jan 23, 2016 at 07:14:33PM +0100, Dmitry Vyukov wrote: >>> I've attached my .config. >>> Also run this program in a parallel loop. I think

net: GPF in netlink_getsockbyportid

Hello, The following program causes GPF in netlink_getsockbyportid: // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #include #include #include #include int main() { syscall(SYS_mmap, 0x2000ul, 0xe65000ul, 0x3ul, 0x32ul,

Re: net: GPF in netlink_getsockbyportid

Dmitry Vyukov wrote: [ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ] > The following program causes GPF in netlink_getsockbyportid: > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #include > #include > #include > #include >

Re: struct pid memory leak

On Sat, Jan 23, 2016 at 7:40 PM, Willy Tarreau wrote: > On Sat, Jan 23, 2016 at 07:14:33PM +0100, Dmitry Vyukov wrote: >> I've attached my .config. >> Also run this program in a parallel loop. I think it's leaking not >> every time, probably some race is involved. > > Thank you. Just

Re: [PATCH] net: dsa: fix mv88e6xxx switches

On Sat, Jan 23, 2016 at 10:51:16AM +, Russell King wrote: > Since commit 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del > ops"), the Marvell 88E6xxx switch has been unable to pass traffic > between ports - any received traffic is discarded by the switch. > Taking a port out of

Re: [PATCH] net: dsa: fix mv88e6xxx switches

On Sat, Jan 23, 2016 at 07:15:26PM +0100, Andrew Lunn wrote: > Thanks for digging into this. I hope you saw v2, which is functionally identical. > I think this is a step towards a solution, but does not solve all the > problems. > > e.g. I have a switch interface lan0 with the IP address >

Re: [PATCH] net: dsa: fix mv88e6xxx switches

> This shows port 0 is on vlan 0, but it should default to vlan 1 when > no vlans are configured. The patch below should at least allow some > diagnosis of what's being requested, and when. > > diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c > index

Re: [PATCH] net: dsa: fix mv88e6xxx switches

On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote: > > This shows port 0 is on vlan 0, but it should default to vlan 1 when > > no vlans are configured. The patch below should at least allow some > > diagnosis of what's being requested, and when. > > > > diff --git

Re: [PATCH] net: dsa: fix mv88e6xxx switches

On Sat, Jan 23, 2016 at 11:23:26PM +0100, Andrew Lunn wrote: > On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote: > > Hi Russell > > > > Never called. > > > > So i guess we have a kernel configuration difference. > > > > I don't have CONFIG_BRIDGE_VLAN_FILTERING. > > Yep, confirmed.

Re: struct pid memory leak

On Sat, Jan 23, 2016 at 07:46:45PM +0100, Dmitry Vyukov wrote: > On Sat, Jan 23, 2016 at 7:40 PM, Willy Tarreau wrote: > > On Sat, Jan 23, 2016 at 07:14:33PM +0100, Dmitry Vyukov wrote: > >> I've attached my .config. > >> Also run this program in a parallel loop. I think it's leaking

Re: struct pid memory leak

On Sat, Jan 23, 2016 at 06:50:11PM -0800, Eric Dumazet wrote: > On Sat, Jan 23, 2016 at 6:38 PM, Willy Tarreau wrote: > > On Sun, Jan 24, 2016 at 03:11:45AM +0100, Willy Tarreau wrote: > >> It doesn't report this on 3.10. > > > > To be more precise, kmemleak reports the issue on 3.13

[PATCH] 82xx: FCC: Fixing a bug causing to FCC port lock-up (second try)

This is an additional patch to the one already submitted recently. The previous patch was not complete, and the FCC port lock-up scenario has been reproduced in lab. I had an opportunity to check the current patch in lab and the FCC port lock no longer freezes, while the previous patch still

Re: net: GPF in netlink_getsockbyportid

Daniel Borkmann wrote: > On 01/23/2016 08:25 PM, Florian Westphal wrote: > >Dmitry Vyukov wrote: > > > >[ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ] > > > >>The following program causes GPF in netlink_getsockbyportid: [..] >

Re: struct pid memory leak

On Sun, Jan 24, 2016 at 03:11:45AM +0100, Willy Tarreau wrote: > It doesn't report this on 3.10. To be more precise, kmemleak reports the issue on 3.13 and not on 3.12. I'm not sure if it's reliable enough to run a bisect though. Willy

Re: [PATCH] net: dsa: fix mv88e6xxx switches

On Sat, Jan 23, 2016 at 09:16:47PM +0100, Andrew Lunn wrote: > On Sat, Jan 23, 2016 at 07:48:57PM +, Russell King - ARM Linux wrote: > > On Sat, Jan 23, 2016 at 08:37:05PM +0100, Andrew Lunn wrote: > > > I'm testing on a 6172. But 6172 and 6176 are both in the same family > > > 6352, and share

Re: [PATCH/RFC v3 net-next] ravb: Add dma queue interrupt support

Hello. On 01/17/2016 01:55 PM, Yoshihiro Kaneko wrote: From: Kazuya Mizuguchi This patch supports the following interrupts. - One interrupt for multiple (descriptor, error, management) - One interrupt for emac - Four interrupts for dma queue (best effort

Re: struct pid memory leak

On Sat, Jan 23, 2016 at 6:38 PM, Willy Tarreau wrote: > On Sun, Jan 24, 2016 at 03:11:45AM +0100, Willy Tarreau wrote: >> It doesn't report this on 3.10. > > To be more precise, kmemleak reports the issue on 3.13 and not on 3.12. > I'm not sure if it's reliable enough to run a bisect

[PATCH] net: fec: make driver endian-safe

The driver treats the device descriptors as CPU-endian, which is probably right on both ARM (little-endian) and PowerPC (big-endian) but wrong on big-endian ARM. Add the correct annotations and byteswaps. This gets it working on i.MX6 hummingboard booted in big-endian mode. Signed-off-by:

Re: [PATCH] net: dsa: fix mv88e6xxx switches

Hi Russell, Russell King - ARM Linux writes: > On Sat, Jan 23, 2016 at 11:23:26PM +0100, Andrew Lunn wrote: >> On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote: >> > Hi Russell >> > >> > Never called. >> > >> > So i guess we have a kernel configuration

Re: net: fec: make driver endian-safe

On Sat, 2016-01-23 at 23:09 +0100, Johannes Berg wrote: >  > +/* buffer endianness appears to be a mess ... ARM is usually LE but > can be BE */ > +#if defined(CONFIG_ARM) && defined(CONFIG_CPU_BIG_ENDIAN) Just realized that this is, of course, completely wrong. If the ARM CPU is little endian,