From: Marek Lindner <mareklindner@neomailbox.ch>
To: b.a.t.m.a.n@lists.open-mesh.org
Cc: Antonio Quartulli <antonio@open-mesh.com>,
Antonio Quartulli <antonio@meshcoding.com>
Subject: Re: [B.A.T.M.A.N.] [PATCHv5 maint] batman-adv: fix TT VLAN inconsistency on VLAN re-add
Date: Wed, 14 May 2014 20:27:09 +0800 [thread overview]
Message-ID: <1718357.L1GdmN95yh@diderot> (raw)
In-Reply-To: <1399561995-10066-1-git-send-email-antonio@meshcoding.com>
[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]
On Thursday 08 May 2014 17:13:15 Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> When a VLAN interface (on top of batX) is removed and
> re-added within a short timeframe TT does not have enough
> time to properly cleanup. This creates an internal TT state
> mismatch as the newly created softif_vlan will be
> initialized from scratch with a TT client count of zero
> (even if TT entries for this VLAN still exist). The
> resulting TT messages are bogus due to the counter / tt
> client listing mismatch, thus creating inconsistencies on
> every node in the network
>
> To fix this issue destroy_vlan() has to not free the VLAN
> object immediately but it has to be kept alive until all the
> TT entries for this VLAN have been removed. destroy_vlan()
> still removes the sysfs folder so that the user has the
> feeling that everything went fine.
>
> If the same VLAN is re-added before the old object is free'd,
> then the latter is resurrected and re-used.
>
> Implement such behaviour by increasing the reference counter
> of a softif_vlan object every time a new local TT entry for
> such VLAN is created and remove the object from the list
> only when all the TT entries have been destroyed.
>
> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
> ---
>
> Changes since v4:
> - improved code in add_vid()
> - don't leak TT entries in case of vlan re-add failure
>
> Changes since v3:
> - always re-add NO_PURGE local entry on add_vid()
>
> Changes since v2:
> - remove cleanup_work member that is not needed anymore in this approach
> - reword commit subject
> - reword commit message (Thanks Marek!)
>
> Changes since v1:
> - destroy and create vlan sysfs folder within softif_vlan_destroy/create()
> to avoid lock troubles with soft-interface destruction and delayed jobs.
>
>
> soft-interface.c | 60
> ++++++++++++++++++++++++++++++++++++++++------------- translation-table.c |
> 26 +++++++++++++++++++++++
> types.h | 2 ++
> 3 files changed, 74 insertions(+), 14 deletions(-)
Applied in revision 9729d20.
Thanks,
Marek
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
prev parent reply other threads:[~2014-05-14 12:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 15:13 [B.A.T.M.A.N.] [PATCHv5 maint] batman-adv: fix TT VLAN inconsistency on VLAN re-add Antonio Quartulli
2014-05-14 12:27 ` Marek Lindner [this message]
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=1718357.L1GdmN95yh@diderot \
--to=mareklindner@neomailbox.ch \
--cc=antonio@meshcoding.com \
--cc=antonio@open-mesh.com \
--cc=b.a.t.m.a.n@lists.open-mesh.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox