netdev - Re: [net-next v2] tipc: update a binding service via broadcast

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20200617.085448.2300826067257423419.davem@davemloft.net>
Date:   Wed, 17 Jun 2020 08:54:48 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     hoang.h.le@...tech.com.au
Cc:     ying.xue@...driver.com, netdev@...r.kernel.org, jmaloy@...hat.com,
        maloy@...jonn.com, lkp@...el.com
Subject: Re: [net-next v2] tipc: update a binding service via broadcast

From: Hoang Huu Le <hoang.h.le@...tech.com.au>
Date: Wed, 17 Jun 2020 13:56:05 +0700

> Currently, updating binding table (add service binding to
> name table/withdraw a service binding) is being sent over replicast.
> However, if we are scaling up clusters to > 100 nodes/containers this
> method is less affection because of looping through nodes in a cluster one
> by one.
> 
> It is worth to use broadcast to update a binding service. This way, the
> binding table can be updated on all peer nodes in one shot.
> 
> Broadcast is used when all peer nodes, as indicated by a new capability
> flag TIPC_NAMED_BCAST, support reception of this message type.
> 
> Four problems need to be considered when introducing this feature.
> 1) When establishing a link to a new peer node we still update this by a
> unicast 'bulk' update. This may lead to race conditions, where a later
> broadcast publication/withdrawal bypass the 'bulk', resulting in
> disordered publications, or even that a withdrawal may arrive before the
> corresponding publication. We solve this by adding an 'is_last_bulk' bit
> in the last bulk messages so that it can be distinguished from all other
> messages. Only when this message has arrived do we open up for reception
> of broadcast publications/withdrawals.
> 
> 2) When a first legacy node is added to the cluster all distribution
> will switch over to use the legacy 'replicast' method, while the
> opposite happens when the last legacy node leaves the cluster. This
> entails another risk of message disordering that has to be handled. We
> solve this by adding a sequence number to the broadcast/replicast
> messages, so that disordering can be discovered and corrected. Note
> however that we don't need to consider potential message loss or
> duplication at this protocol level.
> 
> 3) Bulk messages don't contain any sequence numbers, and will always
> arrive in order. Hence we must exempt those from the sequence number
> control and deliver them unconditionally. We solve this by adding a new
> 'is_bulk' bit in those messages so that they can be recognized.
> 
> 4) Legacy messages, which don't contain any new bits or sequence
> numbers, but neither can arrive out of order, also need to be exempt
> from the initial synchronization and sequence number check, and
> delivered unconditionally. Therefore, we add another 'is_not_legacy' bit
> to all new messages so that those can be distinguished from legacy
> messages and the latter delivered directly.
> 
> v1->v2:
>  - fix warning issue reported by kbuild test robot <lkp@...el.com>
>  - add santiy check to drop the publication message with a sequence
> number that is lower than the agreed synch point
> 
> Signed-off-by: kernel test robot <lkp@...el.com>
> Signed-off-by: Hoang Huu Le <hoang.h.le@...tech.com.au>
> Acked-by: Jon Maloy <jmaloy@...hat.com>

Applied, thank you.