On Fri, Mar 15, 2019 at 07:26:11PM -0700, Jakub Kicinski wrote:
> On Fri, 15 Mar 2019 17:56:07 +, Petr Machata wrote:
> > diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
> > index e2091bb2b3a8..cfd9e86ff0ca 100644
> > --- a/include/net/rtnetlink.h
> > +++ b/include/net/rtnetlink.
From: Eric Dumazet
Date: Sat, 16 Mar 2019 13:09:53 -0700
> In my latest patch I missed one rcu_read_unlock(), in case
> device is down.
>
> Fixes: 4477138fa0ae ("tun: properly test for IFF_UP")
> Signed-off-by: Eric Dumazet
> Reported-by: syzbot
Applied, thanks Eric.
In my latest patch I missed one rcu_read_unlock(), in case
device is down.
Fixes: 4477138fa0ae ("tun: properly test for IFF_UP")
Signed-off-by: Eric Dumazet
Reported-by: syzbot
---
drivers/net/tun.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index
On 03/14/2019 08:19 PM, Eric Dumazet wrote:
> Same reasons than the ones explained in commit 4179cb5a4c92
> ("vxlan: test dev->flags & IFF_UP before calling netif_rx()")
>
> netif_rx_ni() or napi_gro_frags() must be called under a strict contract.
>
> At device dismantle phase, core networking
From: Daniel Borkmann
Date: Sat, 16 Mar 2019 01:43:56 +0100
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) Fix a umem memory leak on cleanup in AF_XDP, from Björn.
>
> 2) Fix BTF to properly resolve forward-declared enums into their corr
On Sat, Mar 16, 2019 at 8:12 AM Heiner Kallweit wrote:
>
> On 16.03.2019 15:38, VDR User wrote:
> >> Part of the issue though is that we don't know how reliable that test
> >> was. I believe Derek he hasn't had any crashes, but he wasn't confident
> >> that it had actually resolved the issue.
> >
On 16.03.2019 15:38, VDR User wrote:
>> Part of the issue though is that we don't know how reliable that test
>> was. I believe Derek he hasn't had any crashes, but he wasn't confident
>> that it had actually resolved the issue.
>
> Previously I thought I could easily & consistently reproduce the
> Part of the issue though is that we don't know how reliable that test
> was. I believe Derek he hasn't had any crashes, but he wasn't confident
> that it had actually resolved the issue.
Previously I thought I could easily & consistently reproduce the crash
but the more testing I did, the more I
On 16.03.2019 00:54, Alexander Duyck wrote:
> On Fri, 2019-03-15 at 23:27 +0100, Heiner Kallweit wrote:
>> On 15.03.2019 23:09, Alexander Duyck wrote:
>>> On Fri, 2019-03-15 at 21:46 +0100, Heiner Kallweit wrote:
On 15.03.2019 21:40, Alexander Duyck wrote:
> On Fri, 2019-03-15 at 21:26 +01
Commit ad6c9986bcb62 ("vxlan: Fix GRO cells race condition between
receive and link delete") fixed a race condition for the typical case a vxlan
device is dismantled from the current netns. But if a netns is dismantled,
vxlan_destroy_tunnels() is called to schedule a unregister_netdevice_queue()
of
Hi Leandro,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
url:
https://github.com/0day-ci/linux/commits/Leandro-Dorileo/net-sched-taprio-cbs-Fix-using-invalid-link-speed/20190316-161006
config: riscv-allyesconfig (attached as .config
If tunnel registration failed during module initialization, the module
would fail to deregister the IPPROTO_COMP protocol and would attempt to
deregister the tunnel.
The tunnel was not deregistered during module-exit.
Fixes: d9ee3444014e ("vti4: Fix a ipip packet processing bug in 'IPCOMP'
virtu
Some fixes for the initialization and clean-up of the ipip tunnel.
Jeremy Sowden (2):
vti4: ipip tunnel deregistration fixes.
vti4: removed duplicate log message.
Since v1:
* submitted both patches as one set.
* cc'ed the IPSec maintainers.
net/ipv4/ip_vti.c | 9 -
1 file changed
Removed info log-message if ipip tunnel registration fails during
module-initialization: it adds nothing to the error message that is
written on all failures.
Fixes: d9ee3444014e ("vti4: Fix a ipip packet processing bug in 'IPCOMP'
virtual tunnel")
Signed-off-by: Jeremy Sowden
---
net/ipv4/ip_v
From: Dmitry Bogdanov
TCP/UDP checksum validity was propagated to skb
only if IP checksum is valid.
But for IPv6 there is no validity as there is no checksum in IPv6.
This patch propagates TCP/UDP checksum validity regardless of IP checksum.
Fixes: 018423e90bee ("net: ethernet: aquantia: Add rin
15 matches
Mail list logo