All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	netdev@vger.kernel.org, davem@davemloft.net,
	vivien.didelot@savoirfairelinux.com,
	jerome.oufella@savoirfairelinux.com, cphealy@gmail.com
Subject: Re: [PATCH RFC 1/2] net: dsa: integrate with SWITCHDEV for HW bridging
Date: Sun, 22 Feb 2015 20:38:20 -0800	[thread overview]
Message-ID: <54EAAEBC.6080609@roeck-us.net> (raw)
In-Reply-To: <20150223042220.GA20063@lunn.ch>

On 02/22/2015 08:22 PM, Andrew Lunn wrote:
> On Sun, Feb 22, 2015 at 08:07:03PM -0800, Guenter Roeck wrote:
>> On 02/22/2015 07:14 PM, Andrew Lunn wrote:
>>> On Sun, Feb 22, 2015 at 06:20:44PM -0800, Guenter Roeck wrote:
>>>> On 02/17/2015 11:26 AM, Florian Fainelli wrote:
>>>>> In order to support bridging offloads in DSA switch drivers, select
>>>>> NET_SWITCHDEV to get access to the port_stp_update and parent_get_id
>>>>> NDOs that we are required to implement.
>>>>>
>>>>> To facilitate the integratation at the DSA driver level, we implement 3
>>>>> types of operations:
>>>>>
>>>>
>>>> Hi Florian,
>>>>
>>>>>
>>>>> +/* Return a bitmask of all ports being currently bridged. Note that on
>>>>> + * leave, the mask will still return the bitmask of ports currently bridged,
>>>>> + * prior to port removal, and this is exactly what we want.
>>>>> + */
>>>>> +static u32 dsa_slave_br_port_mask(struct dsa_switch *ds)
>>>>> +{
>>>>> +	unsigned int port;
>>>>> +	u32 mask = 0;
>>>>> +
>>>>> +	for (port = 0; port < DSA_MAX_PORTS; port++) {
>>>>> +		if (!((1 << port) & ds->phys_port_mask))
>>>>> +			continue;
>>>>> +
>>>>> +		if (ds->ports[port]->priv_flags & IFF_BRIDGE_PORT)
>>>>> +			mask |= 1 << port;
>>>>
>>>> Problem is that the function can be called through dsa_slave_netdevice_event
>>>> before the slave devices are fully initialized.
>>>>
>>>> After adding
>>>>
>>>> +               if (!ds->ports[port]) {
>>>> +                       netdev_err(bridge,
>>>> +                                  "No ports data for port %d, mask=0x%x\n",
>>>> +                                  port, ds->phys_port_mask);
>>>> +                       continue;
>>>> +               }
>>>>
>>>> and with some more debug messages added to dsa_switch_setup(), I see the following.
>>>>
>>>> [   14.187290] e1000e 0000:00:19.0 em1: [0]: Creating slave device for port 1(port1)
>>>> [   14.272605] e1000e 0000:00:19.0 em1: [0]: Creating slave device for port 2(port2)
>>>> [   14.353118] e1000e 0000:00:19.0 em1: [0]: Creating slave device for port 3(port3)
>>>> [   14.472002] br0: No ports data for port 3, mask=0x1e
>>>> [   14.472053] br0: No ports data for port 4, mask=0x1e
>>>> [   14.472753] e1000e 0000:00:19.0 em1: [0]: Creating slave device for port 4(host2esb)
>>>>
>>>> This happens if I add the bridge configuration to /etc/network/interfaces instead
>>>> of creating the bridge manually. Apparently dsa_switch_setup() is not yet complete
>>>> when dsa_slave_netdevice_event is executed to handle a state change on one of its
>>>> newly created slave interfaces.
>>>>
>>>> The relevant information from /etc/network/interfaces is:
>>>>
>>>> auto br0
>>>>
>>>> iface port1 inet manual
>>>> iface port2 inet manual
>>>>
>>>> iface br0 inet dhcp
>>>> 	bridge_ports port1 port2
>>>
>>> Hi Guenter
>>>
>>> Does this actually matter? The ports which don't exists yet are not
>>> being added to the bridge. The mask will come out correct. What
>>> happens when port4 is made a member of the bridge? I expect it
>>> works. It is the creation of the interface which triggers hotplug to
>>> read interfaces and add the interface to the port.
>>>
>>
>> 	if (!ds->ports[port])
>> 		continue;
>>
>> might be an option. However, I am not sure that what you say is correct,
>> at least not strictly speaking. dsa_slave_create() returns the created
>> slave device, which is added to ds->ports[port] in dsa_switch_setup().
>> Since there is no protection in dsa_switch_setup(), there is no guarantee
>> that the callback doesn't happen prior to the initialization of
>> ds->ports[port]. So the above would leave a race condition, where the
>> port being added to the bridge _is_ one for which ds->ports[port] is
>> not yet initialized.
>
> Yes, you are correct, there is a race here.
>
>
>> Protecting the entire slave creation loop in dsa_switch_setup()
>> and using register_netdevice() in dsa_slave_create() solves the problem
>> as far as I can see, I just don't know if it is an acceptable solution.
>
> Or:
>
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index 2173402d87e0..1aa120d6d0e4 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -325,8 +325,6 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int index,
>                                     index, i, pd->port_names[i]);
>                          continue;
>                  }
> -
> -               ds->ports[i] = slave_dev;
>          }
>
>   #ifdef CONFIG_NET_DSA_HWMON
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index f23deadf42a0..d6004072a957 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -669,12 +669,14 @@ dsa_slave_create(struct dsa_switch *ds, struct device *parent,
>                  free_netdev(slave_dev);
>                  return NULL;
>          }
> +       ds->ports[port] = slave_dev;
>
>          ret = register_netdev(slave_dev);
>          if (ret) {
>                  netdev_err(master, "error %d registering interface %s\n",
>                             ret, slave_dev->name);
>                  phy_disconnect(p->phy);
> +               ds->ports[port] = NULL;
>                  free_netdev(slave_dev);
>                  return NULL;
>          }
>
> Not tested. But the point being, ensure everything is setup before
> calling register_netdev().
>

That should work. I'll give it a try.

Guenter

  parent reply	other threads:[~2015-02-23  4:38 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 19:26 [PATCH RFC 0/2] net: dsa: integration with SWITCHDEV for HW bridging Florian Fainelli
2015-02-17 19:26 ` [PATCH RFC 1/2] net: dsa: integrate " Florian Fainelli
2015-02-17 20:13   ` Guenter Roeck
2015-02-17 20:24     ` Florian Fainelli
2015-02-17 20:28       ` Guenter Roeck
2015-02-18  1:19   ` Andrew Lunn
2015-02-18  1:43     ` Florian Fainelli
2015-02-18  3:53     ` Guenter Roeck
2015-02-18  4:53       ` Florian Fainelli
2015-02-18  6:14         ` Guenter Roeck
2015-02-18 13:49         ` Andrew Lunn
2015-02-18 14:05           ` Guenter Roeck
2015-02-23  2:20   ` Guenter Roeck
2015-02-23  3:14     ` Andrew Lunn
2015-02-23  4:07       ` Guenter Roeck
2015-02-23  4:22         ` Andrew Lunn
2015-02-23  4:33           ` Florian Fainelli
2015-02-23  4:38           ` Guenter Roeck [this message]
2015-02-23  4:43             ` Florian Fainelli
2015-02-23  6:19               ` Guenter Roeck
2015-02-23 13:34               ` Andrew Lunn
2015-02-23 14:23                 ` Guenter Roeck
2015-02-23 16:01                   ` Andrew Lunn
2015-02-23 18:05                     ` Florian Fainelli
2015-02-23 18:35                       ` Guenter Roeck
2015-02-25 13:43                         ` Andrey Volkov
2015-02-25 14:25                           ` Guenter Roeck
2015-02-25 16:05                             ` Andrey Volkov
2015-02-25 17:41                               ` Guenter Roeck
2015-02-26  1:18                                 ` Andrey Volkov
2015-02-27 17:09                             ` Andrey Volkov
2015-02-28  7:53                               ` Guenter Roeck
2015-03-02 14:38                                 ` Andrey Volkov
2015-03-02 14:49                                   ` Guenter Roeck
2015-03-02 15:27                                     ` Andrey Volkov
2015-03-02 17:16                                       ` Guenter Roeck
2015-03-04 10:07                                         ` Andrey Volkov
2015-02-17 19:26 ` [PATCH RFC 2/2] net: dsa: bcm_sf2: implement HW bridging operations Florian Fainelli
2015-02-19  2:48   ` Florian Fainelli
2015-02-19  5:59     ` Guenter Roeck
2015-02-19 17:27       ` Florian Fainelli
2015-02-19 17:46         ` Guenter Roeck
2015-02-19 23:50           ` Florian Fainelli
2015-02-20  0:09             ` Guenter Roeck
2015-02-20  0:51               ` roopa
2015-02-20  1:03                 ` Guenter Roeck
2015-02-20  1:46                   ` roopa
2015-02-20  2:00                     ` Florian Fainelli
2015-02-20  2:41                       ` roopa
2015-02-20  4:05                         ` Guenter Roeck
2015-02-20  4:58                           ` Scott Feldman
2015-02-20  4:59                           ` roopa
2015-02-20  3:20                       ` Andy Gospodarek
2015-02-20  3:53                         ` Viswanath Bandaru
2015-02-20  3:56                         ` Andy Gospodarek
2015-02-20  2:18                     ` Andrew Lunn
2015-02-20  2:51                       ` roopa
2015-02-20  3:52                         ` Andrew Lunn
2015-02-20  4:07                           ` Guenter Roeck
2015-02-20  2:02               ` Andrew Lunn
2015-02-20  3:55                 ` Guenter Roeck
2015-02-20  2:03               ` Florian Fainelli
2015-02-20  2:46                 ` roopa
2015-02-18  0:48 ` [PATCH RFC 0/2] net: dsa: integration with SWITCHDEV for HW bridging Scott Feldman
2015-02-18  1:09   ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54EAAEBC.6080609@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=andrew@lunn.ch \
    --cc=cphealy@gmail.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=jerome.oufella@savoirfairelinux.com \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@savoirfairelinux.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.