All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Quartulli <a@unstable.cc>
To: Sven Eckelmann <sven@narfation.org>
Cc: Jetmir Gigollai <jetmir_gigollaj@web.de>,
	The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [RFC] batman-adv: Remove recursive bat-on-bat netdevice check
Date: Tue, 19 Jan 2016 08:39:07 +0800	[thread overview]
Message-ID: <569D85AB.9080403@unstable.cc> (raw)
In-Reply-To: <1447443981-28246-1-git-send-email-sven@narfation.org>

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

Hi Sven and thanks for this RFC. Sorry for taking soo long to comment.



On 14/11/15 03:46, Sven Eckelmann wrote:
> batman-adv checks in different situation if a new device is already on top
> of a different batman-adv device. This is done by getting the iflink of a
> device and all its parent. It assumes that this iflink is always a parent
> device in an acyclic graph. But this assumption is broken by devices like
> veth which are actually a pair of two devices linked to each other. The
> recursive check would therefore get veth0 when calling dev_get_iflink on
> veth1. And it gets veth0 when calling dev_get_iflink with veth1.
> 

I agree that this check implemented this way represents a problem.
However I also believe that we should still have some kind of prevention
against this particular scenario (chain of batman interfaces), because
if ignored it could lead to troubles.

Unfortunately I don't know how to implement this check in an elegant and
extendible manner.

First of all we should add a check that follows the master interface,
but at the same time we should still follow the iflink, otherwise we
can't check relationships like VLAN_DEV->REAL_DEV. But how to implement
the latter without hitting the cyclic case is not clear to me ..

An option is to add a specific check for veth and break the recursion,
but this is not really nice, because the next time a cyclic interface
type will be introduced our check will become troublesome again.

Suggestions?


Cheers,

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-01-19  0:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13 19:46 [B.A.T.M.A.N.] [RFC] batman-adv: Remove recursive bat-on-bat netdevice check Sven Eckelmann
2016-01-19  0:39 ` Antonio Quartulli [this message]
2016-01-19  1:22   ` Andrew Lunn
2016-01-19 12:34     ` Antonio Quartulli
2016-01-19 14:40       ` Andrew Lunn

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=569D85AB.9080403@unstable.cc \
    --to=a@unstable.cc \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=jetmir_gigollaj@web.de \
    --cc=sven@narfation.org \
    /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.