From: Sven Eckelmann <sven@narfation.org>
To: b.a.t.m.a.n@lists.open-mesh.org
Cc: Marek Lindner <mareklindner@neomailbox.ch>
Subject: Re: [B.A.T.M.A.N.] [RFC maint] batman-adv: fix adding VLANs with partial state
Date: Thu, 10 May 2018 18:11:35 +0200 [thread overview]
Message-ID: <6716451.vJRGfGX9qT@sven-edge> (raw)
In-Reply-To: <20180510152752.2557-1-mareklindner@neomailbox.ch>
[-- Attachment #1: Type: text/plain, Size: 3036 bytes --]
On Donnerstag, 10. Mai 2018 17:27:52 CEST Marek Lindner wrote:
> Whenever a new VLAN is created on top of batman virtual interfaces
> the batman-adv kernel module creates internal structures to track
> the status of said VLAN. Amongst other things, the MAC address of
> the VLAN interface itself has to be stored.
>
> Without this change a VLAN and its infrastructure could be created
> while the interface MAC address is not stored without triggering
> any error, thus creating issues in other parts of the code.
>
> Prevent the VLAN from being created if the MAC address can not
> be stored.
>
> Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Fixes: 952cebb57518 ("batman-adv: add per VLAN interface attribute framework")
??
[....]
> @@ -604,13 +605,18 @@ int batadv_softif_create_vlan(struct batadv_priv
*bat_priv, unsigned short vid)
> /* add a new TT local entry. This one will be marked with the NOPURGE
> * flag
> */
> - batadv_tt_local_add(bat_priv->soft_iface,
> - bat_priv->soft_iface->dev_addr, vid,
> - BATADV_NULL_IFINDEX, BATADV_NO_MARK);
> + client_added = batadv_tt_local_add(bat_priv->soft_iface,
> + bat_priv->soft_iface->dev_addr, vid,
> + BATADV_NULL_IFINDEX, BATADV_NO_MARK);
>
> /* don't return reference to new softif_vlan */
> batadv_softif_vlan_put(vlan);
>
> + if (!client_added) {
> + batadv_softif_destroy_vlan(bat_priv, vlan);
> + return -ENOENT;
> + }
> +
This function (batadv_softif_destroy_vlan) is static and cannot be reached
from here. The definition+declaration of this function follows the function
were you've added these changes.
[...]
> @@ -683,9 +690,14 @@ static int batadv_interface_add_vid(struct net_device
*dev, __be16 proto,
> * flag. This must be added again, even if the vlan object already
> * exists, because the entry was deleted by kill_vid()
> */
> - batadv_tt_local_add(bat_priv->soft_iface,
> - bat_priv->soft_iface->dev_addr, vid,
> - BATADV_NULL_IFINDEX, BATADV_NO_MARK);
> + client_added = batadv_tt_local_add(bat_priv->soft_iface,
> + bat_priv->soft_iface->dev_addr, vid,
> + BATADV_NULL_IFINDEX, BATADV_NO_MARK);
> +
> + if (!client_added) {
> + batadv_softif_destroy_vlan(bat_priv, vlan);
> + return -ENOENT;
> + }
This looks quite fragile to me. Wouldn't that mean that the vlan would also
not be created later? When I remember it correctly, then
batadv_interface_add_vid is the only one which would create the internal vlan
entries in the first place (beside this odd call in batadv_hard_if_event). The
VLAN functionality would therefore be completely broken when such a problem
happens.
1. batadv_interface_add_vid is called
2. vlan is added
3. local entry is not added for this vlan
3.1. vlan is removed again
4. node tries to communicate over this vlan
Btw. it is really odd to see code shared between batadv_interface_add_vid and
batadv_softif_create_vlan. Especially because batadv_interface_add_vid calls
batadv_softif_create_vlan.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-05-10 16:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-10 15:27 [B.A.T.M.A.N.] [RFC maint] batman-adv: fix adding VLANs with partial state Marek Lindner
2018-05-10 16:11 ` Sven Eckelmann [this message]
2018-05-10 16:24 ` Antonio Quartulli
2018-05-10 17:02 ` Sven Eckelmann
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=6716451.vJRGfGX9qT@sven-edge \
--to=sven@narfation.org \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=mareklindner@neomailbox.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox