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, th
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 difference.
>> >
>> > I don't
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 and not on 3.
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 though.
>
> W
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
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 not
> >> ever
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:
[..]
> >CONFIG_NETLINK_MMAP and nfnetlink batching strike
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 locks-
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. W
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 a/drivers/net/dsa/mv8
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 rx/tx, network control rx/tx)
This p
> 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 a43354ed0607..8a9cf67eb1
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: Johann
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
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 initiall
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
#include
#include
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 it's leaking not
>>> every time, pro
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 network/interf
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 towar
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
> #include
>
> int main()
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
> 192.1
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 in order to c
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 ?
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,
0xul
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 brid
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 syzkalle
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:
> e
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.
>
> Ye
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 th
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] https://lists
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 tr
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 case is that of bo
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 ar
33 matches
Mail list logo
