at line 1839 in tipc_link.c
if (unlikely(!msg_short(msg)
(msg_destnode(msg) != tipc_own_addr)))
goto cont;
and recompile. If it works now, my theory is confirmed.
I've copied Jon Maloy on this email as he has a lot more history with
TIPC's link code than I
Hi,
1) You do tipc_send2name(ref,name(1,1)) with an empty
message to establish the connection to
the topology server.
2) The server will respond with an empty message, which
will fulfil the connection. Just ignore this message.
No need to do connect2port(),it is already done by
SOCK_RDM (just as SOCK_STREAM) with TIPC guarantees both delivery and
ordering if you use it on a connection. And the sender will block if the
responder doesn't read fast enough.
However, if you use it connectionless the messages will be rejected when
the reception queue in the receiving socket
reference counter as we
should do.
This commit fixes this bug.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/node.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 3f7a4ed..fa97d96 100644
--- a/net/t
plementation.
Acked-by: Ying Xue <ying@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/link.c | 2 --
net/tipc/node.c | 18 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 7059c9
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Thursday, 02 June, 2016 10:10
> To: tipc-discussion@lists.sourceforge.net; Jon Maloy; ma...@donjonn.com; Ying
> Xue; Richard Alpe
> Subject: [PATCH iproute2 v3 09/10] tipc: add link monitor list
>
>
> -Original Message-
> From: Erik Hugne [mailto:erik.hu...@gmail.com]
> Sent: Wednesday, 08 June, 2016 15:39
> To: Ying Xue
> Cc: Jon Maloy; Richard Alpe; Parthasarathy Bhuvaragan; tipc-
> discuss...@lists.sourceforge.net
> Subject: Re: [RFC PATCH] tipc: fix timer
> -Original Message-
> From: Ying Xue [mailto:ying@windriver.com]
> Sent: Tuesday, 07 June, 2016 12:12
> To: ma...@donjonn.com; erik.hu...@ericsson.com
> Cc: Jon Maloy; Ying Xue; tipc-discussion@lists.sourceforge.net
> Subject: [PATCH] tipc: fix suspicious RCU u
Acked-by: me
///jon
> -Original Message-
> From: Ying Xue [mailto:ying@windriver.com]
> Sent: Tuesday, 07 June, 2016 12:12
> To: ma...@donjonn.com; erik.hu...@ericsson.com
> Cc: Jon Maloy; Ying Xue; tipc-discussion@lists.sourceforge.net
> Subject: [PATC
> -Original Message-
> From: Xue, Ying [mailto:ying@windriver.com]
> Sent: Saturday, 04 June, 2016 10:12
> To: Jon Maloy; Erik Hugne
> Cc: Richard Alpe; Parthasarathy Bhuvaragan; tipc-
> discuss...@lists.sourceforge.net
> Subject: RE: [RFC PATCH] tipc: fix timer
mutex sk_lock.owned instead of sk_lock.slock in
tipc_sk_respond(). This is safer, since sk_lock.slock may
occasionally and briefly be held (by concurrent user contexts)
even if we are in user context.
Reported-by: GUNA <gbala...@gmail.com>
Signed-off-by: Jon M
gmail.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/socket.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 88bfcd7..b19c73c 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -278,7
On 05/24/2016 12:16 PM, GUNA wrote:
> I suspect there could be glitch on switch may cause lost the probe or
> abort message. However, even if the messages are lost for what ever
> reason, is not TIPC stack should handle the graceful shutdown of the
> TIPC connection by releasing all the
ing....@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/Makefile | 2 +-
net/tipc/addr.h| 1 +
net/tipc/bearer.c | 8 +-
net/tipc/bearer.h | 2 +-
net/tipc/core.c| 1 +
net/tipc/core.h| 15 +-
net/tipc/link
<gbala...@gmail.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/socket.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 88bfcd7..e8ed3a8 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/
> -Original Message-
> From: Xue, Ying [mailto:ying@windriver.com]
> Sent: Tuesday, 14 June, 2016 05:46
> To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Parthasarathy
> Bhuvaragan;
> Richard Alpe
> Cc: ma...@donjonn.com; gbala...@gmail.com
> Subjec
solution that I believe is the only really safe
one.
Reported-by: GUNA <gbala...@gmail.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/socket.c | 54 ++
1 file changed, 42 insertions(+), 12 deletions(-)
di
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> Sent: Wednesday, 08 June, 2016 15:46
> To: Parthasarathy Bhuvaragan; tipc-discussion@lists.sourceforge.net;
> ma...@donjonn.com; Ying Xue; Richard Alpe
> Subject: Re: [tipc-discussion] [PATCH iprou
> -Original Message-
> From: Xue, Ying [mailto:ying@windriver.com]
> Sent: Monday, 30 May, 2016 14:15
> To: Jon Maloy; GUNA; Jon Maloy; tipc-discussion@lists.sourceforge.net; Erik
> Hugne; Xue Ying (ying.x...@gmail.com)
> Subject: RE: [tipc-discussion] tipc_sk
> -Original Message-
> From: GUNA [mailto:gbala...@gmail.com]
> Sent: Wednesday, 01 June, 2016 19:52
> To: tipc-discussion@lists.sourceforge.net
> Subject: [tipc-discussion] tipc: name table entry is not matched
>
> I am running on Kernel 4.4.0 and do see table Name table mismatch as
>
From: Erik Hugne [mailto:erik.hu...@gmail.com]
Sent: Thursday, 02 June, 2016 14:11
To: Ying Xue
Cc: Richard Alpe; Parthasarathy Bhuvaragan; Jon Maloy;
tipc-discussion@lists.sourceforge.net
Subject: RE: [RFC PATCH] tipc: fix timer handling when socket is owned
On Jun 2, 2016 1:03 PM, &quo
ble.
Acked-by: Ying Xue <ying....@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/Makefile | 2 +-
net/tipc/addr.h| 1 +
net/tipc/bearer.c | 8 +-
net/tipc/bearer.h | 2 +-
net/tipc/core.c| 1 +
net/tipc/core.h| 15 +-
net/tip
On 06/22/2016 11:40 AM, Erik Hugne wrote:
> This change is not backwards compatible, udp_media_addr is carried in the
> neighbor discovery messages.
>
> //E
Not sure if backwards compatibility is a big issue at this stage, but as
I remember it the 'media_id' field was meant to fulfill this
Same for me.
Acked-by: jon
///jon
On 06/23/2016 06:23 AM, Xue, Ying wrote:
> The other two patches look good for me.
>
> Regards,
> Ying
>
> -Original Message-
> From: Richard Alpe [mailto:richard.a...@ericsson.com]
> Sent: Thursday, June 23, 2016 6:02 PM
> To: Erik Hugne
> Cc:
e function
tipc_bcast_rcv(), which is trying to access the not-yet existing link.
We fix this by deferring the addition of the node instance until after
it has been fully initialized in the function tipc_node_create().
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/node.c | 12
Anybody who has time to look into this?
///jon
On 02/19/2016 06:41 PM, Jon Maloy wrote:
> The compatibility functionality has been broken, and causes a crash as
> shown below:
>
> Bisecting seems to indicate that the culprit is:
>
> commit 263ea09084d172cac6e40459a690babe8
ng Xue <ying@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/node.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 9fcc2fb..792bbcb 100644
--- a/net/tipc/node.c
+++ b/net/tipc/n
ng Xue <ying@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/node.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 792bbcb..cdb7950 100644
--- a/net/tipc/node.c
+++ b/n
one should notice that row 4 and 6 are mutually
exclusive, which means that the counter never goes to zero prematurely.
Reported-by: Jason Huzhijiang <huzhiji...@gmail.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/node.c | 5 +++--
1 file changed, 3 insertions(+), 2
first place.
Reported-by: Jason Huzhijiang <huzhiji...@gmail.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/node.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 9d7a16f..50285de 100644
--- a/net/tipc/node
;
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/node.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index e1c9e39..67f4fe5 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -150,
first place.
Reported-by: Jason Huzhijiang <huzhiji...@gmail.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/node.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 9d7a16f..50285de 100644
--- a/net/tipc/node
> -Original Message-
> From: Xue, Ying [mailto:ying@windriver.com]
> Sent: Tuesday, 16 February, 2016 08:42
> To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Parthasarathy
> Bhuvaragan;
> Richard Alpe; huzhiji...@gmail.com
> Cc: ma...@donjonn.com
> Subj
Hi Paolo,
Yes you can. You can create a kernel socket with AF_TIPC from any module and
use it the way you wish.
If you want an example, look at the topology server (server.{h,c},
subcsr.{h,c}) inside the TIPC module itself.
Regards
///jon
> -Original Message-
> From: Pablo Pessolani
> an offline peer node from the internal data structures.
>
> This will be supported by the tipc user space tool in iproute2.
>
> Signed-off-by: Richard Alpe <richard.a...@ericsson.com>
> Reviewed-by: Jon Maloy <jon.ma...@ericsson.com>
> Acked-by: Ying Xue <ying
(), which makes this
very easy to fix. I was misled by our bad experience from the link
timer, where we ran into deadlocks.
This cannot happen with the node timer.
///jon
>
> Regards,
> Ying
>
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
&
again.
kfree_rcu() // BOOM!
We fix this by introducing use of the conditional kref_get_if_not_zero()
instead of kref_get() in the function tipc_node_find(). This eliminates
any risk of post-mortem access.
Reported-by: Zhijiang Hu <huzhiji...@gmail.com>
Signed-off-by: Jon M
The compatibility functionality has been broken, and causes a crash as
shown below:
Bisecting seems to indicate that the culprit is:
commit 263ea09084d172cac6e40459a690babe8de8e448
("Revert "genl: Add genlmsg_new_unicast() for unicast message allocation")
///jon
value of mod_timer() in tipc_node_timeout(),
and don't touch kref.
Reported-by: Zhijiang Hu <huzhiji...@gmail.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/node.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/net/tipc
with the actual size of the header, not the
allocated headroom.
///jon
> -Original Message-
> From: Richard Alpe
> Sent: Thursday, 10 March, 2016 10:53
> To: tipc-discussion@lists.sourceforge.net
> Cc: Jon Maloy; Parthasarathy Bhuvaragan; erik.hu...@gmail.com; Richard
> -Original Message-
> From: Richard Alpe
> Sent: Thursday, 10 March, 2016 05:27
> To: tipc-discussion@lists.sourceforge.net
> Cc: Jon Maloy; Parthasarathy Bhuvaragan; erik.hu...@gmail.com; Richard Alpe
> Subject: [PATCH tipc-discussion] tipc: fix headroom of
Still weird that this starts happening now, when this issue is supposed to be
remedied, and not earlier, when it wasn't.
We really need that "permit overlapping publications" solution I have been
preaching about.
Br
///jon
> -Original Message-
> From: Rune Torgersen
nal Message-
> From: Erik Hugne [mailto:erik.hu...@gmail.com]
> Sent: Wednesday, 09 March, 2016 16:03
> To: tipc-discussion@lists.sourceforge.net
> Cc: Richard Alpe; Jon Maloy; Parthasarathy Bhuvaragan; Erik Hugne
> Subject: [PATCH] tipc: remove nonexisting function from link.h
>
transmit
functions at the bearer layer, we now free the indicated buffer or
buffer chain when a valid bearer cannot be found.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/bearer.c | 51 ++-
net/tipc/discover.
Commit #1 fixes a potential issue with deferred binding table
updates being pushed to the wrong namespace.
Commit #2 solves a problem with deferred binding table updates
remaining in the the defer queue after the issuing node has gone
down.
Erik Hugne (2):
tipc: make dist queue pernet
tipc:
When fix a minor buffer leak, and ensure that bearers filter packets
correctly while they are being shut down.
v2: Corrected typos in commit #3, as per feedback from S. Shtylyov
v3: Removed commit #3 from the series. Improved version will be
re-submitted later.
Jon Maloy (2):
tipc
transmit
functions at the bearer layer, we now free the indicated buffer or
buffer chain when a valid bearer cannot be found.
Acked-by: Ying Xue <ying@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/bea
ing@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/bearer.c | 50 +-
net/tipc/msg.h| 5 +
2 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
i
this were a locally
detected connectivity failure, and hence has to go through a full two-
way setup message exchange before any link can be re-established.
Although never reported, this problem seems to have always been around.
This protocol addition is fully backwards compatible.
Signed-off-by:
en extra send
call to the bearer immediately after the link has come up.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/node.c | 4
1 file changed, 4 insertions(+)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index ace178f..b00e12c 100644
--- a/net/tipc/node.c
+++
t;1.1.5:829961004>829961004
> cluster
> 17075168 4 4 <1.1.9:1415618317> 1415618317
>cluster
> 17075168 4 4 <1.1.10:2146874377>2146874377
>cluster
>
> There are around 200
transmit
functions at the bearer layer, we now free the indicated buffer or
buffer chain when a valid bearer cannot be found.
Acked-by: Ying Xue <ying@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/bea
reset. We will then experience a worst-case
re-establishing time of 6 seconds, something we deem acceptable.
Acked-by: Ying Xue <ying@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/link.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
> -Original Message-
> From: Rune Torgersen [mailto:ru...@innovsys.com]
> Sent: Tuesday, 05 April, 2016 12:12
> To: Jon Maloy; 'Jon Maloy'; tipc-discussion@lists.sourceforge.net
> Cc: erik.hu...@gmail.com; Richard Alpe; Parthasarathy Bhuvaragan; Xue Ying
> (ying.x...@gm
> -Original Message-
> From: Richard Alpe
> Sent: Tuesday, 12 April, 2016 03:45
> To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Parthasarathy
> Bhuvaragan;
> Ying Xue
> Cc: ma...@donjonn.com
> Subject: Re: [PATCH net-next v2 3/5] tipc: refactor funct
I just made an "apt-get install iproute2" on Ubuntu 16.04 (Xenial), and could
finally confirm that the tipc tool now is built by default for this package.
I had to issue a TR to make them do this.
/jon
--
Find and fix
.
v2: Added a commit #5
This series serves as base for the commit "tipc: add neighbor
monitoring framework"
Jon Maloy (5):
tipc: guarantee peer bearer id exchange after reboot
tipc: reduce transmission rate of reset messages when link is down
tipc: refactor function tipc_li
The function tipc_link_timeout() is unnecessary complex, and can
easily be made more readable.
We do that with this commit. The only functional change is that we
remove a redundant test for whether the broadcast link is up or not.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
ne
()
bearer_xmit()//pkt #3
bearer_xmit() //pkt #1
}
We could of course have fixed this by passing the same queue along everywhere,
but it is too intrusive for such a small problem.
///jon
From: Jon Maloy [mailto:ma...@donjonn.com]
Sent: Tuesday, 12 April
der
to make the commit easily appliable to 'net' and 'stable'.
We now move this linearization to where it should be done, in the
functions tipc_named_rcv() and tipc_link_proto_rcv() respectively.
Reviewed-by: Ying Xue <ying@windriver.com>
Signed-off-by: Jon Maloy &
Hi Guna,
See below.
On 04/08/2016 03:45 PM, GUNA wrote:
> I have merged the fixes listed below into 4.4.0 kernel and rebuilt tipc
> module.
> Now, the links are look stable.
Hm, I thought your "unstable" links were just due to your audit script.
Nothing was changed in the patches you were
nd domain
records are marked with a generation number. This saves senders from
unecessarily conveying unchanged domain records, and receivers from
performing unneeded re-adaptations of their node monitoring list, such
as re-assigning domain heads.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.c
Partha,Richard,
I think you are the experts on this now. To me it looks like a message rejected
(probably because of overload, according to previous mail exchange with GUNA)
back to a socket on the local node is not being dropped, as it should. Maybe we
have overload both at sender and
Hi Leon,
No wonder it wasn't working ;)
Yes, -be is obligatory. That is how you tell TIPC which interface(s) to use for
communication with other nodes.
But again, -netid is not needed.
///jon
From: Leon Pollak [mailto:le...@plris.com]
Sent: Tuesday, 22 March, 2016 08:31
To: Jon Maloy
Cc
; key=0
> Mar 22 10:34:34 mitchelltelctrl2 kernel: Dropping name table update (0) of
> {0, 0,
> 16600} from <1.1.1> key=4294915584
>
> but they do not mention port 104.
>
> If I restart the application on 1 having 104:1025 open, it shows up on 2.
>
&g
Hi,
This is not a known problem. Looking at the dump and the code it may
look as if somebody is sending in a TIPC_ADDR_NAMEd message with a zero
sockaddr pointer.
This should of course not lead to a kernel crash, but it might still
give a hint of what is triggering the problem, so you can get
Richard, this is kernel 2.6.37. I doubt very much that the 'tipc' tool will
work with that kernel version. Correct me if I am wrong.
Anyway, I am pretty sure that the choice of tool is not the issue here; to try
changing it would just cause him unnecessary extra work.
Leon, just a control
gt; key=0
> Mar 22 10:34:34 mitchelltelctrl2 kernel: Dropping name table update (0) of
> {0, 0, 0} from <1.1.1> key=0
> Mar 22 10:34:34 mitchelltelctrl2 kernel: Dropping name table update (0) of
> {0, 0, 0} from <1.1.1> key=0
> Mar 22 10:34:34 mitchelltelctrl2 kernel:
time a bearer is enabled.
In this commit, we release the buffers or buffer chains in all the
three send functions if no bearer can be found.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/bearer.c | 45 ++---
1 file changed, 22 inse
will then experience a worst-case
re-establishing time of 6 seconds, something we deem acceptable.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/link.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 7d2bb3e..d92d530
Acked-by: Jon Maloy
///jon
> -Original Message-
> From: Richard Alpe
> Sent: Wednesday, 02 March, 2016 12:11
> To: tipc-discussion@lists.sourceforge.net
> Cc: Jon Maloy; Ying Xue; Parthasarathy Bhuvaragan; Richard Alpe
> Subject: [PATCH v1 4/4] tipc: make sure requi
Forget about the reminder below. I just saw in my private mailbox (but not the
Ericsson one, for some reason) that Ying had acked it.
I will post the patch asap.
///jon
> -Original Message-
> From: Jon Maloy
> Sent: Thursday, 03 March, 2016 10:07
> To: Jon Maloy; tip
Acked-by: Jon
///jon
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Thursday, 03 March, 2016 11:28
> To: tipc-discussion@lists.sourceforge.net; Jon Maloy; ma...@donjonn.com; Ying
> Xue; Richard Alpe; Anders Widell
> Subject: [PATCH net v1 1/1] tipc:
ing@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/bcast.c | 5 ---
net/tipc/bcast.h | 1 -
net/tipc/link.c | 114 ++-
net/tipc/link.h | 1 -
net/tipc/net.c | 1 -
5 files changed, 45 insertions(+),
guaranteed.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/msg.h| 1 +
net/tipc/name_distr.c | 76 +--
net/tipc/name_distr.h | 3 +-
net/tipc/node.c | 44 +
net/tipc/node.h
dropped.
BR
///jon
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> Sent: Sunday, 03 April, 2016 22:18
> To: tipc-discussion@lists.sourceforge.net; Parthasarathy Bhuvaragan; Ying Xue;
> Richard Alpe; Jon Maloy
> Cc: ma...@donjonn.com
> Sub
Hi Leon,
Yes, you are running TIPC 2.0, but that does not really mean much. The version
number hasn't changed the last 4-5 years, while huge parts of the code has been
fundamentally rewritten during that period.
There were several issues like the one you have encountered, and almost all of
will then experience a worst-case
re-establishing time of 6 seconds, something we deem acceptable.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/link.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 7d2bb3e..d92d530
transmit
functions at the bearer layer, we now free the indicated buffer or
buffer chain when a valid bearer cannot be found.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/bearer.c | 51 ++-
net/tipc/discover.
use the fact that the device's user pointer now is zero to filter out
which packets can be sent during this situation; i.e., outgoing RESET
messages only. This filtering serves to speed up the neighbors'
detection of the loss event, and saves us from unnecessary probing.
Signed-off-by: Jon Maloy
r own kernel, so you could try out a patch from us
and confirm my theory before we deliver such a solution upstream?
Regards
///jon
> -Original Message-
> From: Rune Torgersen [mailto:ru...@innovsys.com]
> Sent: Thursday, 31 March, 2016 14:56
> To: 'Jon Maloy'; tipc-discussion
Thanks, Erik. I missed that part ;)
But this still doesn't explain why completely regular and valid
publications end up in the backlog at at all.
I still believe my theory about this might be right. I'll post a patch
shortly.
///jon
On 04/02/2016 04:52 AM, Erik Hugne wrote:
> Nametable
the corresponding publications could not be
found in the table. Were those entries visible in the table of 1.1.1 before you
rebooted? My guess is not...
///jon
> -Original Message-
> From: Rune Torgersen [mailto:ru...@innovsys.com]
> Sent: Monday, 04 April, 2016 11:11
> To: Jon Maloy
> -Original Message-
> From: Rune Torgersen [mailto:ru...@innovsys.com]
> Sent: Monday, 04 April, 2016 09:53
> To: Jon Maloy; 'Jon Maloy'; tipc-discussion@lists.sourceforge.net
> Cc: erik.hu...@gmail.com; Richard Alpe; Parthasarathy Bhuvaragan
> Subject: RE: [tip
er disable
here, since we cannot know when to enable it again unless
we have kept the bearer instance. Hopefully resolved the
atomicity problem (which I frankly don't see as a real
problem) as described in feedback from Ying.
Jon Maloy (4):
tipc: remove remnants of old broa
transmit
functions at the bearer layer, we now free the indicated buffer or
buffer chain when a valid bearer cannot be found.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/bearer.c | 51 ++-
net/tipc/discover.
will then experience a worst-case
re-establishing time of 6 seconds, something we deem acceptable.
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
---
net/tipc/link.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 7d2bb3e..d92d530
use the fact that the device's user pointer now is zero to filter out
which packets can be sent during this situation; i.e., outgoing RESET
messages only. This filtering serves to speed up the neighbors'
detection of the loss event, and saves us from unnecessary probing.
Signed-off-by: Jon Maloy
We remove a couple of leftover fields in struct tipc_bearer. Those
were used by the old broadcast implementation, and are not needed
any longer. There is no functional changes in this commit.
Acked-by: Ying Xue <ying@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com&
Hi Ying,
See below.
///jon
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> Sent: Monday, 25 April, 2016 09:54
> To: Ying Xue; tipc-discussion@lists.sourceforge.net; Parthasarathy Bhuvaragan;
> Richard Alpe
> Subject: Re: [tipc-discussion] [PAT
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Friday, 22 April, 2016 09:01
> To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Ying Xue; Richard Alpe
> Cc: ma...@donjonn.com
> Subject: Re: [PATCH net-next v2 1/1] tipc: add neighbor mo
"steady" ones?
///jon
>
> Thanks,
> Hamish Martin.
>
>
> On 04/29/2016 02:09 PM, Jon Maloy wrote:
>> (Removed netdev from list, added some others).
>>
>> This is interesting, and must it have been hard to track. But I would
>> really like to know
> -Original Message-
> From: GUNA [mailto:gbala...@gmail.com]
> Sent: Friday, 29 April, 2016 10:48
> To: Jon Maloy
> Cc: tipc-discussion@lists.sourceforge.net
> Subject: Re: Tipc: name table mismatch between different cards in a system
>
> The two skb_lineariz
Yes. And I issued a bug report and followed it up, so it is now also fixed in
kernel 4.4, which will be in mainline 16.04 very soon.
BR
///jon
> -Original Message-
> From: Rune Torgersen [mailto:ru...@innovsys.com]
> Sent: Tuesday, 26 April, 2016 13:53
> To: Jon Maloy
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Tuesday, 26 April, 2016 11:30
> To: Jon Maloy; Ying Xue; tipc-discussion@lists.sourceforge.net; Richard Alpe
> Subject: Re: [tipc-discussion] [PATCH net-next v3 1/1] tipc: add neighbor
> monitoring fra
Hi Partha,
See below.
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Thursday, 28 April, 2016 10:16
> To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Ying Xue; Richard Alpe
> Cc: ma...@donjonn.com
> Subject: Re: [PATCH net-next v3 1/1] tipc: add n
Hi Guna,
see below.
> -Original Message-
> From: GUNA [mailto:gbala...@gmail.com]
> Sent: Thursday, 28 April, 2016 10:27
> To: tipc-discussion@lists.sourceforge.net
> Subject: [tipc-discussion] Kernel 4.4.0 TIPC: links were bouncing and not
> stable
> enough
>
> Hi Jon,
>
> Back to
> -Original Message-
> From: GUNA [mailto:gbala...@gmail.com]
> Sent: Thursday, 28 April, 2016 17:43
> To: tipc-discussion@lists.sourceforge.net
> Subject: [tipc-discussion] Tipc: name table mismatch between different cards
> in a
> system
>
> After upgraded CPU cards to 4.4.0 Kernel,
: Ying Xue <ying@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
Signed-off-by: David S. Miller <da...@davemloft.net>
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 9efbdbd..fa452fb 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.
destination address. Did you find out where these messages
really came from, and why they have wrong destination addresses?
///jon
> -Original Message-
> From: Hamish Martin [mailto:hamish.mar...@alliedtelesis.co.nz]
> Sent: Thursday, 28 April, 2016 21:35
> To: Jo
1 - 100 of 969 matches
Mail list logo
