netdev - Re: [net-next v3] tipc: support in-order name publication events

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]

Date:   Thu, 21 Nov 2019 15:04:55 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     tuong.t.lien@...tech.com.au
Cc:     jon.maloy@...csson.com, maloy@...jonn.com, ying.xue@...driver.com,
        netdev@...r.kernel.org, tipc-discussion@...ts.sourceforge.net
Subject: Re: [net-next v3] tipc: support in-order name publication events

From: Tuong Lien <tuong.t.lien@...tech.com.au>
Date: Thu, 21 Nov 2019 15:34:58 +0700

> It is observed that TIPC service binding order will not be kept in the
> publication event report to user if the service is subscribed after the
> bindings.
> 
> For example, services are bound by application in the following order:
> 
> Server: bound port A to {18888,66,66} scope 2
> Server: bound port A to {18888,33,33} scope 2
> 
> Now, if a client subscribes to the service range (e.g. {18888, 0-100}),
> it will get the 'TIPC_PUBLISHED' events in that binding order only when
> the subscription is started before the bindings.
> Otherwise, if started after the bindings, the events will arrive in the
> opposite order:
> 
> Client: received event for published {18888,33,33}
> Client: received event for published {18888,66,66}
> 
> For the latter case, it is clear that the bindings have existed in the
> name table already, so when reported, the events' order will follow the
> order of the rbtree binding nodes (- a node with lesser 'lower'/'upper'
> range value will be first).
> 
> This is correct as we provide the tracking on a specific service status
> (available or not), not the relationship between multiple services.
> However, some users expect to see the same order of arriving events
> irrespective of when the subscription is issued. This turns out to be
> easy to fix. We now add functionality to ensure that publication events
> always are issued in the same temporal order as the corresponding
> bindings were performed.
> 
> v2: replace the unnecessary macro - 'publication_after()' with inline
> function.
> v3: reuse 'time_after32()' instead of reinventing the same exact code.
> 
> Acked-by: Jon Maloy <jon.maloy@...csson.com>
> Signed-off-by: Tuong Lien <tuong.t.lien@...tech.com.au>

Applied, thanks.