netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next] bridge: remove a redundant synchronize_net()
@ 2013-04-02 15:45 Eric Dumazet
  2013-04-02 15:58 ` Veaceslav Falico
  0 siblings, 1 reply; 11+ messages in thread
From: Eric Dumazet @ 2013-04-02 15:45 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Veaceslav Falico, Stephen Hemminger

From: Eric Dumazet <edumazet@google.com>

commit 00cfec37484761 (net: add a synchronize_net() in
netdev_rx_handler_unregister())
allows us to remove the synchronized_net() call from del_nbp()

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Veaceslav Falico <vfalico@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
 net/bridge/br_if.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index ef1b914..f17fcb3 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -148,7 +148,6 @@ static void del_nbp(struct net_bridge_port *p)
 	dev->priv_flags &= ~IFF_BRIDGE_PORT;
 
 	netdev_rx_handler_unregister(dev);
-	synchronize_net();
 
 	netdev_upper_dev_unlink(dev, br->dev);
 

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH net-next] bridge: remove a redundant synchronize_net()
  2013-04-02 15:45 [PATCH net-next] bridge: remove a redundant synchronize_net() Eric Dumazet
@ 2013-04-02 15:58 ` Veaceslav Falico
  2013-04-02 16:12   ` David Miller
  0 siblings, 1 reply; 11+ messages in thread
From: Veaceslav Falico @ 2013-04-02 15:58 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev, Stephen Hemminger

On Tue, Apr 02, 2013 at 08:45:00AM -0700, Eric Dumazet wrote:
>From: Eric Dumazet <edumazet@google.com>
>
>commit 00cfec37484761 (net: add a synchronize_net() in
>netdev_rx_handler_unregister())
>allows us to remove the synchronized_net() call from del_nbp()
>
>Signed-off-by: Eric Dumazet <edumazet@google.com>
>Cc: Veaceslav Falico <vfalico@redhat.com>
>Cc: Stephen Hemminger <stephen@networkplumber.org>
>---
> net/bridge/br_if.c |    1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>index ef1b914..f17fcb3 100644
>--- a/net/bridge/br_if.c
>+++ b/net/bridge/br_if.c
>@@ -148,7 +148,6 @@ static void del_nbp(struct net_bridge_port *p)
> 	dev->priv_flags &= ~IFF_BRIDGE_PORT;
>
> 	netdev_rx_handler_unregister(dev);
>-	synchronize_net();
>
> 	netdev_upper_dev_unlink(dev, br->dev);
>
>
>

Thanks, didn't see that when fixing bonding.

Acked-by: Veaceslav Falico <vfalico@redhat.com>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH net-next] bridge: remove a redundant synchronize_net()
  2013-04-02 15:58 ` Veaceslav Falico
@ 2013-04-02 16:12   ` David Miller
  2013-04-02 16:27     ` Eric Dumazet
  0 siblings, 1 reply; 11+ messages in thread
From: David Miller @ 2013-04-02 16:12 UTC (permalink / raw)
  To: vfalico; +Cc: eric.dumazet, netdev, stephen

From: Veaceslav Falico <vfalico@redhat.com>
Date: Tue, 2 Apr 2013 17:58:22 +0200

> On Tue, Apr 02, 2013 at 08:45:00AM -0700, Eric Dumazet wrote:
>>From: Eric Dumazet <edumazet@google.com>
>>
>>commit 00cfec37484761 (net: add a synchronize_net() in
>>netdev_rx_handler_unregister())
>>allows us to remove the synchronized_net() call from del_nbp()
>>
>>Signed-off-by: Eric Dumazet <edumazet@google.com>
 ...
> Acked-by: Veaceslav Falico <vfalico@redhat.com>

Applied.

Note that we have a few spots now that do two synchronize_net()'s per
opertaion, such as team port removal, and openvswitch has such a path
as well.  They all are of the form:

	netdev_rx_handler_unregister()
	...
	lots of other stuff
	...
	synchronize_net();

So might be harder to factor back out than this br_if.c case.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH net-next] bridge: remove a redundant synchronize_net()
  2013-04-02 16:12   ` David Miller
@ 2013-04-02 16:27     ` Eric Dumazet
  2013-04-02 18:19       ` David Miller
  2013-04-04 15:35       ` Jiri Pirko
  0 siblings, 2 replies; 11+ messages in thread
From: Eric Dumazet @ 2013-04-02 16:27 UTC (permalink / raw)
  To: David Miller; +Cc: vfalico, netdev, stephen, Jiri Pirko

On Tue, 2013-04-02 at 12:12 -0400, David Miller wrote:

> Note that we have a few spots now that do two synchronize_net()'s per
> opertaion, such as team port removal, and openvswitch has such a path
> as well.  They all are of the form:
> 
> 	netdev_rx_handler_unregister()
> 	...
> 	lots of other stuff
> 	...
> 	synchronize_net();
> 
> So might be harder to factor back out than this br_if.c case.
> 

Strange, I do see call_rcu() in openvswitch, not a synchronize_{net|
rcu}(). Probably OK to leave as is, as it's not a big deal.

I'll let Jiri handle the team driver change, as its not clear what
synchronize_rcu() call in team_port_del() is protecting

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH net-next] bridge: remove a redundant synchronize_net()
  2013-04-02 16:27     ` Eric Dumazet
@ 2013-04-02 18:19       ` David Miller
  2013-04-04 15:35       ` Jiri Pirko
  1 sibling, 0 replies; 11+ messages in thread
From: David Miller @ 2013-04-02 18:19 UTC (permalink / raw)
  To: eric.dumazet; +Cc: vfalico, netdev, stephen, jiri

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 02 Apr 2013 09:27:57 -0700

> On Tue, 2013-04-02 at 12:12 -0400, David Miller wrote:
> 
>> Note that we have a few spots now that do two synchronize_net()'s per
>> opertaion, such as team port removal, and openvswitch has such a path
>> as well.  They all are of the form:
>> 
>> 	netdev_rx_handler_unregister()
>> 	...
>> 	lots of other stuff
>> 	...
>> 	synchronize_net();
>> 
>> So might be harder to factor back out than this br_if.c case.
>> 
> 
> Strange, I do see call_rcu() in openvswitch, not a synchronize_{net|
> rcu}(). Probably OK to leave as is, as it's not a big deal.

My bad, I misread the code.

> I'll let Jiri handle the team driver change, as its not clear what
> synchronize_rcu() call in team_port_del() is protecting

Ok.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH net-next] bridge: remove a redundant synchronize_net()
  2013-04-02 16:27     ` Eric Dumazet
  2013-04-02 18:19       ` David Miller
@ 2013-04-04 15:35       ` Jiri Pirko
  2013-04-04 15:44         ` Eric Dumazet
  1 sibling, 1 reply; 11+ messages in thread
From: Jiri Pirko @ 2013-04-04 15:35 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, vfalico, netdev, stephen

Tue, Apr 02, 2013 at 06:27:57PM CEST, eric.dumazet@gmail.com wrote:
>On Tue, 2013-04-02 at 12:12 -0400, David Miller wrote:
>
>> Note that we have a few spots now that do two synchronize_net()'s per
>> opertaion, such as team port removal, and openvswitch has such a path
>> as well.  They all are of the form:
>> 
>> 	netdev_rx_handler_unregister()
>> 	...
>> 	lots of other stuff
>> 	...
>> 	synchronize_net();
>> 
>> So might be harder to factor back out than this br_if.c case.
>> 
>
>Strange, I do see call_rcu() in openvswitch, not a synchronize_{net|
>rcu}(). Probably OK to leave as is, as it's not a big deal.
>
>I'll let Jiri handle the team driver change, as its not clear what
>synchronize_rcu() call in team_port_del() is protecting

It can be converted now to call_rcu. synchronize_rcu is making sure
no packet is in flight when changing modes.

>
>
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH net-next] bridge: remove a redundant synchronize_net()
  2013-04-04 15:35       ` Jiri Pirko
@ 2013-04-04 15:44         ` Eric Dumazet
  2013-04-04 16:03           ` Eric Dumazet
  2013-04-04 16:07           ` Jiri Pirko
  0 siblings, 2 replies; 11+ messages in thread
From: Eric Dumazet @ 2013-04-04 15:44 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: David Miller, vfalico, netdev, stephen

On Thu, 2013-04-04 at 17:35 +0200, Jiri Pirko wrote:

> It can be converted now to call_rcu. synchronize_rcu is making sure
> no packet is in flight when changing modes.

What changes exactly ? You don't really answer to my question with this
very vague sentence.

Because maybe the synchronize_net() in netdev_rx_handler_unregister()
is enough and you dont even need the call_rcu(). Thats was my question.

RCU barriers are not magical things we add when we are not exactly sure
of what is happening.

Like other barriers (wmb(), smb_wmb(), ...) we should document or
understand why they are needed.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH net-next] bridge: remove a redundant synchronize_net()
  2013-04-04 15:44         ` Eric Dumazet
@ 2013-04-04 16:03           ` Eric Dumazet
  2013-04-04 16:08             ` Jiri Pirko
  2013-04-04 16:07           ` Jiri Pirko
  1 sibling, 1 reply; 11+ messages in thread
From: Eric Dumazet @ 2013-04-04 16:03 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: David Miller, vfalico, netdev, stephen

On Thu, 2013-04-04 at 08:44 -0700, Eric Dumazet wrote:

> Because maybe the synchronize_net() in netdev_rx_handler_unregister()
> is enough and you dont even need the call_rcu(). Thats was my question.

So we have the following sequence in team_port_del()

        netdev_rx_handler_unregister(port_dev);

        netdev_upper_dev_unlink(port_dev, dev);
        team_port_disable_netpoll(port);
        vlan_vids_del_by_dev(port_dev, dev);
        dev_uc_unsync(port_dev, dev);
        dev_mc_unsync(port_dev, dev);
        dev_close(port_dev);
        team_port_leave(team, port);

        __team_option_inst_mark_removed_port(team, port);
        __team_options_change_check(team);
        __team_option_inst_del_port(team, port);
        __team_port_change_port_removed(port);

        team_port_set_orig_dev_addr(port);
        dev_set_mtu(port_dev, port->orig.mtu);
        synchronize_rcu();
        kfree(port);

And I suspect we can remove synchronize_rcu() call.

But as this is a long list of operations, maybe some of them requires
the rcu grace period before kfree(port)

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH net-next] bridge: remove a redundant synchronize_net()
  2013-04-04 15:44         ` Eric Dumazet
  2013-04-04 16:03           ` Eric Dumazet
@ 2013-04-04 16:07           ` Jiri Pirko
  2013-04-04 16:18             ` Eric Dumazet
  1 sibling, 1 reply; 11+ messages in thread
From: Jiri Pirko @ 2013-04-04 16:07 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, vfalico, netdev, stephen

Thu, Apr 04, 2013 at 05:44:47PM CEST, eric.dumazet@gmail.com wrote:
>On Thu, 2013-04-04 at 17:35 +0200, Jiri Pirko wrote:
>
>> It can be converted now to call_rcu. synchronize_rcu is making sure
>> no packet is in flight when changing modes.
>
>What changes exactly ? You don't really answer to my question with this
>very vague sentence.

Sorry for vagueness. We discussed this in thread from Oct 2011:
Subject: [patch net-next V2] net: introduce ethernet teaming device

purpose of synchronize_rcu() here (instead of call_rcu) was to ensure that
rx_handler can not be in progress when __team_change_mode() changes
team->ops.receive to NULL

>
>Because maybe the synchronize_net() in netdev_rx_handler_unregister()
>is enough and you dont even need the call_rcu(). Thats was my question.

Yes, you are right. kfree(port) can be called right away.

>
>RCU barriers are not magical things we add when we are not exactly sure
>of what is happening.

I always thought that synchronize_rcu() is from the magic land of elfs and fairies...

>
>Like other barriers (wmb(), smb_wmb(), ...) we should document or
>understand why they are needed.
>
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH net-next] bridge: remove a redundant synchronize_net()
  2013-04-04 16:03           ` Eric Dumazet
@ 2013-04-04 16:08             ` Jiri Pirko
  0 siblings, 0 replies; 11+ messages in thread
From: Jiri Pirko @ 2013-04-04 16:08 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, vfalico, netdev, stephen

Thu, Apr 04, 2013 at 06:03:45PM CEST, eric.dumazet@gmail.com wrote:
>On Thu, 2013-04-04 at 08:44 -0700, Eric Dumazet wrote:
>
>> Because maybe the synchronize_net() in netdev_rx_handler_unregister()
>> is enough and you dont even need the call_rcu(). Thats was my question.
>
>So we have the following sequence in team_port_del()
>
>        netdev_rx_handler_unregister(port_dev);
>
>        netdev_upper_dev_unlink(port_dev, dev);
>        team_port_disable_netpoll(port);
>        vlan_vids_del_by_dev(port_dev, dev);
>        dev_uc_unsync(port_dev, dev);
>        dev_mc_unsync(port_dev, dev);
>        dev_close(port_dev);
>        team_port_leave(team, port);
>
>        __team_option_inst_mark_removed_port(team, port);
>        __team_options_change_check(team);
>        __team_option_inst_del_port(team, port);
>        __team_port_change_port_removed(port);
>
>        team_port_set_orig_dev_addr(port);
>        dev_set_mtu(port_dev, port->orig.mtu);
>        synchronize_rcu();
>        kfree(port);
>
>And I suspect we can remove synchronize_rcu() call.

I agree.

>
>But as this is a long list of operations, maybe some of them requires
>the rcu grace period before kfree(port)

None of them requires that.

>
>
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH net-next] bridge: remove a redundant synchronize_net()
  2013-04-04 16:07           ` Jiri Pirko
@ 2013-04-04 16:18             ` Eric Dumazet
  0 siblings, 0 replies; 11+ messages in thread
From: Eric Dumazet @ 2013-04-04 16:18 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: David Miller, vfalico, netdev, stephen

On Thu, 2013-04-04 at 18:07 +0200, Jiri Pirko wrote:

> I always thought that synchronize_rcu() is from the magic land of elfs and fairies...


;)

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2013-04-04 16:19 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-02 15:45 [PATCH net-next] bridge: remove a redundant synchronize_net() Eric Dumazet
2013-04-02 15:58 ` Veaceslav Falico
2013-04-02 16:12   ` David Miller
2013-04-02 16:27     ` Eric Dumazet
2013-04-02 18:19       ` David Miller
2013-04-04 15:35       ` Jiri Pirko
2013-04-04 15:44         ` Eric Dumazet
2013-04-04 16:03           ` Eric Dumazet
2013-04-04 16:08             ` Jiri Pirko
2013-04-04 16:07           ` Jiri Pirko
2013-04-04 16:18             ` Eric Dumazet

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).