* [PATCH] tipc: set addr_trail_end when using explicit node addresses
@ 2019-08-07 4:55 Chris Packham
2019-08-08 14:49 ` Jon Maloy
0 siblings, 1 reply; 2+ messages in thread
From: Chris Packham @ 2019-08-07 4:55 UTC (permalink / raw)
To: jon.maloy, ying.xue, davem
Cc: netdev, tipc-discussion, linux-kernel, Chris Packham
When tipc uses auto-generated node addresses it goes through a duplicate
address detection phase to ensure the address is unique.
When using explicitly configured node names the DAD phase is skipped.
However addr_trail_end was being left set to 0 which causes parts of the
tipc state machine to assume that the address is not yet valid and
unnecessarily delays the discovery phase. By setting addr_trail_end to
jiffies when using explicit addresses we ensure that we move straight to
discovery.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
net/tipc/discover.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index c138d68e8a69..f83bfe8c9443 100644
--- a/net/tipc/discover.c
+++ b/net/tipc/discover.c
@@ -361,6 +361,8 @@ int tipc_disc_create(struct net *net, struct tipc_bearer *b,
if (!tipc_own_addr(net)) {
tn->addr_trial_end = jiffies + msecs_to_jiffies(1000);
msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
+ } else {
+ tn->addr_trial_end = jiffies;
}
memcpy(&d->dest, dest, sizeof(*dest));
d->net = net;
--
2.22.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* RE: [PATCH] tipc: set addr_trail_end when using explicit node addresses
2019-08-07 4:55 [PATCH] tipc: set addr_trail_end when using explicit node addresses Chris Packham
@ 2019-08-08 14:49 ` Jon Maloy
0 siblings, 0 replies; 2+ messages in thread
From: Jon Maloy @ 2019-08-08 14:49 UTC (permalink / raw)
To: Chris Packham, ying.xue, davem; +Cc: netdev, tipc-discussion, linux-kernel
You should rather set this one unconditionally in tipc_set_node_addr().
The problems is not about the state machine, but that jiffies is close to the wrap-around time, so that it is perceived as being before the time "0".
BR
///jon
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Chris Packham
> Sent: 7-Aug-19 00:56
> To: Jon Maloy <jon.maloy@ericsson.com>; ying.xue@windriver.com;
> davem@davemloft.net
> Cc: netdev@vger.kernel.org; tipc-discussion@lists.sourceforge.net; linux-
> kernel@vger.kernel.org; Chris Packham <chris.packham@alliedtelesis.co.nz>
> Subject: [PATCH] tipc: set addr_trail_end when using explicit node addresses
>
> When tipc uses auto-generated node addresses it goes through a duplicate
> address detection phase to ensure the address is unique.
>
> When using explicitly configured node names the DAD phase is skipped.
> However addr_trail_end was being left set to 0 which causes parts of the tipc
> state machine to assume that the address is not yet valid and unnecessarily
> delays the discovery phase. By setting addr_trail_end to jiffies when using
> explicit addresses we ensure that we move straight to discovery.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> net/tipc/discover.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/tipc/discover.c b/net/tipc/discover.c index
> c138d68e8a69..f83bfe8c9443 100644
> --- a/net/tipc/discover.c
> +++ b/net/tipc/discover.c
> @@ -361,6 +361,8 @@ int tipc_disc_create(struct net *net, struct
> tipc_bearer *b,
> if (!tipc_own_addr(net)) {
> tn->addr_trial_end = jiffies + msecs_to_jiffies(1000);
> msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
> + } else {
> + tn->addr_trial_end = jiffies;
> }
> memcpy(&d->dest, dest, sizeof(*dest));
> d->net = net;
> --
> 2.22.0
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-08-08 14:50 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-07 4:55 [PATCH] tipc: set addr_trail_end when using explicit node addresses Chris Packham
2019-08-08 14:49 ` Jon Maloy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).