/filesystems/epoll/epoll_wakeup_test.c
(it just adds a second write) shows the different behavior.
The testlet passes with pipe() but fails with socketpair() with 5.10.
They both fail with 4.19.
Is it fair to assume that 5.10 pipe's behavior is the correct one?
Thanks,
Francesco Ruggeri
/*
*
On Wed, Oct 14, 2020 at 1:23 AM Florian Westphal wrote:
>
> Pablo Neira Ayuso wrote:
> > Legacy would still be flawed though.
>
> Its fine too, new rule blob gets handled (and match/target checkentry
> called) before old one is dismantled.
>
> We only have a 0 refcount + hook unregister when rule
On Fri, Oct 9, 2020 at 12:49 PM Jozsef Kadlecsik wrote:
> What is the rationale behind "remove the conntrack hooks when there are no
> rule left referring to conntrack"? Performance optimization?
That seems to be the case. See commit 4d3a57f23dec ("netfilter: conntrack:
do not enable connection t
On Wed, Oct 7, 2020 at 12:32 PM Francesco Ruggeri wrote:
>
> If the first packet conntrack sees after a re-register is an outgoing
> keepalive packet with no data (SEG.SEQ = SND.NXT-1), td_end is set to
> SND.NXT-1.
> When the peer correctly acknowledges SND.NXT, tcp_in_window fa
r than when sending out
the keepalive packet.
Fixes: f94e63801ab2 ("netfilter: conntrack: reset tcp maxwin on re-register")
Signed-off-by: Francesco Ruggeri
---
net/netfilter/nf_conntrack_proto_tcp.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
t I am not sure it is the
correct
Thanks,
Francesco Ruggeri
Fixes: f94e63801ab2 ("netfilter: conntrack: reset tcp maxwin on re-register")
Signed-off-by: Francesco Ruggeri
---
net/netfilter/nf_conntrack_proto_tcp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/netfilter/nf_c
v'
> description in 'WAIT_REFS_MIN_MSECS'
>
> Fixes: 0e4be9e57e8c ("net: use exponential backoff in netdev_wait_allrefs")
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Francesco Ruggeri
Thanks for fixing this!
On Tue, Sep 22, 2020 at 4:22 AM Mauro Carvalho Chehab
wrote:
>
> kernel-doc expects the function prototype to be just after
> the kernel-doc markup, as otherwise it will get it all wrong:
>
> ./net/core/dev.c:10036: warning: Excess function parameter 'dev'
> description in 'WAIT_REFS_MIN_
refs.
v3: preserve reverse christmas tree ordering of local variables
v4: try an extra rcu_barrier before the backoff, plus some
cosmetic changes.
Signed-off-by: Francesco Ruggeri
---
net/core/dev.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/core/de
On Thu, Sep 17, 2020 at 5:02 PM Stephen Hemminger
wrote:
> Is there anyway to make RCU trigger faster?
This is a case of the networking code requiring multiple cascading grace periods
(functions executing at the end of a period scheduling more functions
for the end
of the next period), so it's a
rve reverse christmas tree ordering of local variables
Signed-off-by: Francesco Ruggeri
---
net/core/dev.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 4086d335978c..e5fa60cb8832 100644
--- a/net/core/dev.c
+++ b/net/core
eep(250)
to get out of the loop faster.
Time with this patch on a 5.4 kernel:
real0m8.199s
user0m0.402s
sys 0m1.213s
Time without this patch:
real0m31.522s
user0m0.438s
sys 0m1.156s
v2: use exponential backoff instead of trying to wake up
netdev_wait_allrefs.
Signed
On Wed, Sep 16, 2020 at 11:51 PM Eric Dumazet wrote:
>
> Honestly I would not touch dev_put() at all.
>
> Simply change the msleep(250) to something better, with maybe
> exponential backoff.
OK, I will try that.
Francesco
> static inline void dev_put(struct net_device *dev)
> {
> + struct task_struct *destroy_task = dev->destroy_task;
> +
> this_cpu_dec(*dev->pcpu_refcnt);
> + if (destroy_task)
> + wake_up_process(destroy_task);
> }
I just realized that this introduces a race, i
llowing dev_put to wake up netdev_wait_allrefs.
Time with this patch on a 5.4 kernel:
real0m7.494s
user0m0.403s
sys 0m1.197s
Time without this patch:
real0m31.522s
user0m0.438s
sys 0m1.156s
Signed-off-by: Francesco Ruggeri
---
include/linux/netdevice.h | 6 ++
net
driver"),
commit 8f4c5c9fb87a ("ixgbe: reinit_locked() should be called with
rtnl_lock") and commit 88adce4ea8f9 ("ixgbe: fix possible race in
reset subtask").
v2: add fix for second race condition above.
Signed-off-by: Francesco Ruggeri
---
drivers/net/ethernet/
>
> So will you be sending a v2 of your patch to include the second fix?
Yes, I am working on it. Just to confirm, v2 should include both fixes, right?
Thanks,
Francesco
> Do not worry about the other Intel drivers, I have our developers looking at
> each of our drivers for the locking issue.
>
> @David Miller - I am picking up this patch
There seems to be a second race, independent from the
original one, that results in a divide error:
kworker reboot -f
> Would you mind adding a fixes tag here? Probably:
>
> Fixes: 9d5c824399de ("igb: PCI-Express 82575 Gigabit Ethernet driver")
That seems to be the commit that introduced the driver in 2.6.25.
I am not familiar with the history of the driver to tell if this was a day 1
problem or if it became an i
_state
This commit applies to igb the same changes that were applied to ixgbe
in commit 8f4c5c9fb87a ("ixgbe: reinit_locked() should be called with
rtnl_lock") and commit 88adce4ea8f9 ("ixgbe: fix possible race in
reset subtask").
Signed-off-by: Francesco Ruggeri
---
driv
By default IPv6 socket with IPV6_ROUTER_ALERT socket option set will
receive all IPv6 RA packets from all namespaces.
IPV6_ROUTER_ALERT_ISOLATE socket option restricts packets received by
the socket to be only from the socket's namespace.
Signed-off-by: Maxim Martynov
Signed-off-by: Fran
On Thu, Feb 28, 2019 at 3:31 PM David Ahern wrote:
>
> On 2/28/19 2:02 PM, David Miller wrote:
> > From: frugg...@arista.com (Francesco Ruggeri)
> > Date: Thu, 28 Feb 2019 11:01:46 -0800
> >
> >> ip6_call_ra_chain is called when IPv6 packet with Router Alert
in.
Suggested-by: Maxim Martynov
Signed-off-by: Maxim Martynov
Signed-off-by: Francesco Ruggeri
---
net/ipv6/ip6_output.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 5f9fa0302b5a..3ed25e17dff3 100644
--- a/net/ipv6
]
> SyS_exit_group+0x1d/0x20 kernel/exit.c:977
> entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x44ad19
>
>
> Fixes: 30f7ea1c2b5f ("packet: race condition in packet_bind")
> Signed-off-by: Eric Dumazet
> Reported-by: syzbot
> Cc: F
large number of net namespaces, each having a non-mroute6
raw socket.
v2: same patch, only fixed subject line and expanded comment.
Signed-off-by: Francesco Ruggeri
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index f5500f5..e1bb2d8 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
, 2017 at 12:40 PM, Francesco Ruggeri wrote:
> commit 9634257773c30ce13d74fa4918329612c60d84a8
> Author: Francesco Ruggeri
> Date: Mon Nov 6 11:01:59 2017 -0800
>
> ipv6: try not to take rtnl_lock in ip6mr_sk_done
>
> mrt->mroute6_sk can only be set to a non-NUL
commit 9634257773c30ce13d74fa4918329612c60d84a8
Author: Francesco Ruggeri
Date: Mon Nov 6 11:01:59 2017 -0800
ipv6: try not to take rtnl_lock in ip6mr_sk_done
mrt->mroute6_sk can only be set to a non-NULL value in ip6mr_sk_init()
if sk->sk_type == SOCK_RAW &&a
On Tue, Apr 26, 2016 at 11:54 AM, Mahesh Bandewar wrote:
>
> On Sat, Apr 23, 2016 at 3:03 PM, Francesco Ruggeri
> wrote:
> > If macvlan_common_newlink fails in register_netdevice after macvlan_init
> > then it decrements port->count twice, first in macvlan_uninit (from
&
TER, dev)
macvtap_device_event(NETDEV_REGISTER)
minor = 0>
rollback_registered(dev);
rollback_registered_many
call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
macvtap_device_event(NETDEV_UNREGISTER)
Signed-off-by: Francesco R
tch consolidates modifications to port->count into macvlan_init
and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
v3: remove macvtap specific bits.
Signed-off-by: Francesco Ruggeri
---
drivers/net/macvlan.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff -
On Thu, Apr 21, 2016 at 10:44 AM, Eric W. Biederman
wrote:
<
>> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>> index 95394ed..e770221 100644
>> --- a/drivers/net/macvtap.c
>> +++ b/drivers/net/macvtap.c
>> @@ -1303,6 +1303,8 @@ static int macvtap_device_event(struct notifier_block
tch consolidates modifications to port->count into macvlan_init
and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
In macvtap_device_event it also avoids cleaning up in NETDEV_UNREGISTER
if NETDEV_REGISTER had previously failed.
Signed-off-by: Francesco Ruggeri
---
drivers/net/mac
On Mon, Apr 18, 2016 at 2:33 PM, Eric W. Biederman
wrote:
>
> But please see if you can get macvlan_init to do the necessary work.
> That should simplify everything, and make clever games unnecessary.
Using macvlan_init seems to work. I will test it a couple of days and
then resubmit.
Thanks,
Fr
On Mon, Apr 18, 2016 at 11:48 AM, Eric W. Biederman
wrote:
>
> These interactions all seem a little bit funny. At a quick skim it
> would make more sense to increment the port count in macvlan_init,
> and completely remove the need to mess with port counts anywhere except
> macvlan_init and macvl
exec ns${ns} ip link del ddev &
done
sleep 2
ls /dev/tap*
for ((ns=1; ns<3; ns++))
do
ip netns del ns${ns}
done
Signed-off-by: Francesco Ruggeri
---
drivers/net/macvlan.c | 11 ---
drivers/net/macvtap.c | 2 ++
include/linux/if_macvlan.h | 3 +++
3 files changed, 13
(the local address that had been used for
the tcp connection had been moved out of the router).
Thanks,
Francesco Ruggeri
> I am not sure we want to support ~64K of headers.
>
> Is this something real, or just another root-exploit
> linux-bug-of-the-day trick ?
>
> When I want to reboot my host I usually type 'reboot', as it looks nicer
> to me ;)
>
Thanks Eric.
My point was that an accidental route misconfiguration,
eadroom is unsigned short) skb_cow_head does not
allocate enough headroom in the skb.
I have not been able to come with a solution except not updating a tunnel's
needed_headroom, but that would have a performance impact (see also
http://marc.info/?l=linux-netdev&m=145594279014551&w=2
On Fri, Feb 19, 2016 at 8:26 PM, Francesco Ruggeri wrote:
> Misconfigurations can result in local tunnel loops being created.
> __dev_queue_xmit catches packets caught in a loop and drops them,
> but the affected tunnels' needed_headroom can be corrupted in the
> process as
e gre local 3.3.3.3 remote 4.4.4.4
ip link set t3 up
ip route add 2.2.2.2 dev t3
ip route add 4.4.4.4 dev t1
ping -c 5 2.2.2.2
Signed-off-by: Francesco Ruggeri
---
net/ipv4/ip_tunnel.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net
dst_release should not access dst->flags after decrementing
__refcnt to 0. The dst_entry may be in dst_busy_list and
dst_gc_task may dst_destroy it before dst_release gets a chance
to access dst->flags.
Signed-off-by: Francesco Ruggeri
---
net/core/dst.c | 3 ++-
1 file changed, 2 inse
'
s.close()
os.system('ip netns del dummy')
sys.exit(0)
os.waitpid(pid, 0)
s.close()
os.system('ip netns del dummy')
sys.exit(0)
Signed-off-by: Francesco Ruggeri
---
net/packet/af_packet.c | 80 +++---
1 file changed,
eds
> > to pass a device to flush_backlog since it handles any device in the
> > NETREG_UNREGISTERED state.
> >
> > Signed-off-by: Baptiste Covolato
> > Signed-off-by: Francesco Ruggeri
>
> This is quite bogus if you ask me.
>
> This is the one spot c
43 matches
Mail list logo
