> I've started to notice messages like this when pushing TIPC a bit:
Not sure what you mean by "pushing TIPC a bit". If it means dropping TIPC
messages, then "Retransmission failure" is expected.
>Is there any tuning I can do to avoid the problem, or other data to collect to
>better
>Subject: [PATCH net] tipc: fix a possible memleak in tipc_buf_append
>
>__skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL'
>after __skb_linearize(), so that the skb can be freed on the
>err path.
>
>Fixes: b7df21cf1b79 ("tipc: skb_linearize the head skb when reassembling
>1. As TIPC creates a UDP socket for a bearer and multiple TIPC sockets are
>kind of multiplexed into one UDP socket. Can it slow the
>performance when the incoming traffic is high?
I do not see any performance down in my test when using UDP bearer.
>2. Can we increase the buffer size of the
>As part of the shutdown, we are terminating all the processes using SIGKILL.
>We are expecting the tipc sockets to be closed
>automatically by the kernel after some time.
>
>But sometimes ‘tipc socket list’ is still showing a few sockets as alive.
>
>Now when we restart the application, the
> net/tipc/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/net/tipc/Makefile b/net/tipc/Makefile index
>ee49a9f1dd4f..18e1636aa036 100644
>--- a/net/tipc/Makefile
>+++ b/net/tipc/Makefile
>@@ -18,5 +18,5 @@ tipc-$(CONFIG_TIPC_MEDIA_IB) += ib_media.o
>
> net/tipc/node.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
>diff --git a/net/tipc/node.c b/net/tipc/node.c index
>3105abe97bb9..2a036b8a7da3 100644
>--- a/net/tipc/node.c
>+++ b/net/tipc/node.c
>@@ -2154,14 +2154,15 @@ void tipc_rcv(struct net *net, struct sk_buff *skb,
>>This patch is wrong. le->link and link status must be protected by node lock.
>>See what happens if tipc_node_timeout() is called, and
>the link goes down:
>>tipc_node_timeout()
>> tipc_node_link_down()
>> {
>> struct tipc_link *l = le->link;
>> ...
>> if (delete) {
>>
> I think there was also added a command to force the name table updates
> back to the unicast channel, but I don't remember
> from the top of my head how it was done. Maybe Tung can fill in here?
It is "tipc link set broadcast REPLICAST".
___
> Also, since the publish and unicast is not guaranteed in order, should not
> reception of a unicast data message before a publish update the publish table
> on the receiving end so you can expect to reply back immediately.
No, receiving of user data messages does not update the naming table.
each
> send, but that slows down everthing by several orders of magnitude.
This is the right thing to do.
From: Tung Quang Nguyen
Sent: Wednesday, June 21, 2023 1:41 AM
To: Rune Torgersen ; tipc-discussion@lists.sourceforge.net
Subject: Re: TIPC out-of-order publish message
This email
>if (-1 == bind(sock, (struct sockaddr*)_addr, sizeof(struct
> sockaddr_tipc)))
> perror("Error opening TIPC socket");
> *(int*)buf = addr;
> int rc = sendto(sock, buf, sendsize, 0, (struct sockaddr*)_addr,
> sizeof(to_addr));
You are not recommended to design
>Subject: [PATCH v2] net: tipc: resize nlattr array to correct size
>
>According to nla_parse_nested_deprecated(), the tb[] is supposed to the
>destination array with maxtype+1 elements. In current
>tipc_nl_media_get() and __tipc_nl_media_set(), a larger array is used
>which is unnecessary. This
>I don't really know the difference :D
>
>Since this a not any new feature patch but just solving a typo like bug. I
>guess
>it can go to (net) branch instead the (net-next) ?
>
>Regards
>Lin
>
It is OK to go for net.
Please:
- append "net" to your patch title.
- add Fixes tag to the changelog.
>Subject: [PATCH v1] tipc: resize nlattr array to correct size
>
>According to nla_parse_nested_deprecated(), the tb[] is supposed to the
>destination array with maxtype+1 elements. In current
>tipc_nl_media_get() and __tipc_nl_media_set(), a larger array is used
>which is unnecessary. This patch
>Subject: [PATCH net-next] tipc: replace open-code bearer rcu_dereference
>access in bearer.c
>
>Replace these open-code bearer rcu_dereference access with bearer_get(),
>like other places in bearer.c. While at it, also use tipc_net() instead
>of net_generic(net, tipc_net_id) to get "tn" in
>Subject: [PATCH net-next] tipc: delete tipc_mtu_bad from tipc_udp_enable
>
>Since commit a4dfa72d0acd ("tipc: set default MTU for UDP media"), it's
>been no longer using dev->mtu for b->mtu, and the issue described in
>commit 3de81b758853 ("tipc: check minimum bearer MTU") doesn't exist
>in UDP
> When pushing TIPC a bit hard on some of our servers, I've recently had
> three of them issue clusters of "Gacks on" messages, with two
>of them also issuing "callbacks suppressed" messages. These had kernels from
>5.10 to 6.2, so it doesn't seem like an issue with a
>particular kernel. Here
Hi Tung,
Can you please share your thoughts.
I have responded to your queries in my previous email. Please let me know if
you need any additional information from my end.
Thanks and regards,
Prakash
[Prakash ] We are using iproute2 version-4.20.0-2+deb10u1 on amd64 platform.
Our use case is
>Subject: [PATCHv3 net 0/3] tipc: fix the mtu update in link mtu negotiation
>
>This patchset fixes a crash caused by a too small MTU carried in the
>activate msg. Note that as such malicious packet does not exist in
>the normal env, the fix won't break any application
>
>The 1st patch introduces
>As different media may requires different min mtu, and even the
>same media with different net family requires different min mtu,
>add tipc_bearer_min_mtu() to calculate min mtu accordingly.
>
>This API will be used to check the new mtu when doing the link
>mtu negotiation in the next patch.
>
>When doing link mtu negotiation, a malicious peer may send Activate msg
>with a very small mtu, e.g. 4 in Shuang's testing, without checking for
>the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then
>n->links[bearer_id].mtu is set to 4294967228, which is a overflow of
>'4 -
>-Original Message-
>From: Xin Long
>Sent: Sunday, April 30, 2023 5:41 AM
>To: network dev ; tipc-discussion@lists.sourceforge.net
>Cc: da...@davemloft.net; k...@kernel.org; Eric Dumazet ;
>Paolo Abeni ; Jon Maloy
>
>Subject: [PATCH net 2/2] tipc: do not update mtu if msg_max is too
>-Original Message-
>From: Xin Long
>Sent: Sunday, April 30, 2023 5:41 AM
>To: network dev ; tipc-discussion@lists.sourceforge.net
>Cc: k...@kernel.org; Eric Dumazet ; Paolo Abeni
>; da...@davemloft.net
>Subject: [tipc-discussion] [PATCH net 1/2] tipc: add tipc_bearer_min_mtu to
From: prakash bisht
Sent: Monday, April 17, 2023 11:20 AM
To: tipc-discussion@lists.sourceforge.net; Xin Long ; Tung
Quang Nguyen ; jma...@redhat.com
Subject: Fwd: TIPC socket ( SOCK_SEQPACKET) cleanup issue
Hi John/Xin,Tung,
Any thoughts on my previous email? We are using tipc for our
>-Original Message-
>From: Jon Maloy
>Sent: Saturday, February 4, 2023 1:02 AM
>To: Tung Quang Nguyen ;
>tipc-discussion@lists.sourceforge.net; ma...@donjonn.com;
>ying@windriver.com
>Subject: Re: [tipc-discussion][PATCH v1 1/1] tipc: fix kernel warning when
> -Original Message-
> From: Xin Long
> Sent: Tuesday, June 7, 2022 12:57 AM
> To: tipc-discussion@lists.sourceforge.net
> Subject: Re: [tipc-discussion] [PATCH net-next] tipc: remove inputq from
> tipc_bc_base
>
> fix Jon's email address.
>
> On Mon, Jun 6, 2022 at 1:52 PM Xin Long
On Thu, 3 Mar 2022 04:57:17 + Tung Nguyen wrote:
> diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
> index 473a790f5894..63460183440d 100644
> --- a/net/tipc/bearer.c
> +++ b/net/tipc/bearer.c
> @@ -252,7 +252,7 @@ static int tipc_enable_bearer(struct net *net, const char
> *name,
>
Remove.
-Original Message-
From: Tung Quang Nguyen
Sent: Thursday, June 10, 2021 4:16 PM
To: Jon Maloy ; Menglong Dong
Cc: ying@windriver.com; tipc-discussion@lists.sourceforge.net; Xin Long
; tipc-dek
Subject: RE: [PATCH v2 net-next 0/2] net: tipc: fix FB_MTU eat two pages and do
Remove tipc-dek mail list to avoid bothering other people.
Best regards,
Tung Nguyen
-Original Message-
From: Jon Maloy
Sent: Thursday, June 10, 2021 4:12 PM
To: Menglong Dong
Cc: ying@windriver.com; tipc-discussion@lists.sourceforge.net; Xin Long
; tipc-dek
Subject: Re: [PATCH
Hi Xin,
See my comments inline.
Best regards,
Tung Nguyen
-Original Message-
From: Xin Long
Sent: Thursday, April 29, 2021 2:31 AM
To: network dev ; tipc-discussion@lists.sourceforge.net
Cc: k...@kernel.org; lyl2...@mail.ustc.edu.cn; da...@davemloft.net
Subject: [tipc-discussion]
Acked-by: Tung Nguyen
-Original Message-
From: Hoang Huu Le
Sent: Monday, April 12, 2021 4:02 PM
To: lyl2...@mail.ustc.edu.cn; da...@davemloft.net;
tipc-discussion@lists.sourceforge.net; jma...@redhat.com; ma...@donjonn.com;
ying@windriver.com; Tung Quang Nguyen
Subject: [net
Acked-by: Tung Nguyen
-Original Message-
From: jma...@redhat.com
Sent: Saturday, February 27, 2021 11:55 PM
To: tipc-discussion@lists.sourceforge.net
Cc: Tung Quang Nguyen ; Hoang Huu Le
; Tuong Tong Lien ;
jma...@redhat.com; ma...@donjonn.com; x...@redhat.com; ying@windriver.com
Hi Jon,
Just a minor comment for this patch.
Best regards,
Tung Nguyen
-Original Message-
From: jma...@redhat.com
Sent: Wednesday, December 9, 2020 1:50 AM
To: tipc-discussion@lists.sourceforge.net
Cc: Tung Quang Nguyen ; Hoang Huu Le
; Tuong Tong Lien ;
jma...@redhat.com; ma
Hi Jon,
Some minor comments for this patch (Marked with [Tung]).
Best regards,
Tung Nguyen
-Original Message-
From: jma...@redhat.com
Sent: Wednesday, December 9, 2020 1:50 AM
To: tipc-discussion@lists.sourceforge.net
Cc: Tung Quang Nguyen ; Hoang Huu Le
; Tuong Tong Lien ;
jma
Hi Jon,
Some minor comments for this patch (Marked with [Tung]).
Best regards,
Tung Nguyen
-Original Message-
From: jma...@redhat.com
Sent: Wednesday, December 9, 2020 1:50 AM
To: tipc-discussion@lists.sourceforge.net
Cc: Tung Quang Nguyen ; Hoang Huu Le
; Tuong Tong Lien ;
jma
Hi Jon,
A minor comment for this patch (Marked with [Tung]).
Best regards,
Tung Nguyen
-Original Message-
From: jma...@redhat.com
Sent: Wednesday, December 9, 2020 1:50 AM
To: tipc-discussion@lists.sourceforge.net
Cc: Tung Quang Nguyen ; Hoang Huu Le
; Tuong Tong Lien ;
jma
Hi Jon,
Just one minor comment for this patch (marked with [Tung]").
Best regards,
Tung Nguyen
-Original Message-
From: jma...@redhat.com
Sent: Wednesday, December 9, 2020 1:50 AM
To: tipc-discussion@lists.sourceforge.net
Cc: Tung Quang Nguyen ; Hoang Huu Le
; Tuong Tong Lien ;
Hi Jon,
Some minor comments for this patch (marked with "[Tung]").
Best regards,
Tung Nguyen
-Original Message-
From: jma...@redhat.com
Sent: Wednesday, December 9, 2020 1:50 AM
To: tipc-discussion@lists.sourceforge.net
Cc: Tung Quang Nguyen ; Hoang Huu Le
; Tuong Tong L
Hi Holger,
You said you met this stack trace after migrating to "kernel 5.4". Can you give
us a full version ?
Thanks.
Tung Nguyen
-Original Message-
From: Holger Brunck
Sent: Monday, November 23, 2020 10:00 PM
To: Jon Maloy ; tipc-discussion@lists.sourceforge.net
Cc:
nt: Wednesday, October 28, 2020 3:50 AM
To: Tung Quang Nguyen
Cc: David Miller ; Linux Kernel Network Developers
; tipc-discussion@lists.sourceforge.net
Subject: Re: [tipc-discussion] [net v3 1/1] tipc: fix memory leak caused by
tipc_buf_append()
On Tue, Oct 27, 2020 at 1:09 PM Tung Nguyen
wrot
ailed do clone local mcast rcv buffer" as well.
"
I will check again your new analysis and create the correct patch.
Thanks.
Tung Nguyen
-Original Message-
From: Xin Long
Sent: Monday, October 26, 2020 4:10 PM
To: Tung Quang Nguyen
Cc: tipc-discussion@lists.sourceforge.net;
Hi Jon,
Let's go for this way for now.
Thanks.
Best regards,
Tung Nguyen
-Original Message-
From: Jon Maloy
Sent: Friday, July 19, 2019 10:06 AM
To: Jon Maloy ; Jon Maloy
Cc: mohan.krishna.ghanta.krishnamur...@ericsson.com;
parthasarathy.bhuvara...@gmail.com;
Hi Jon,
See below.
Best regards,
Tung Nguyen
-Original Message-
From: Jon Maloy
Sent: Friday, July 19, 2019 10:05 AM
To: Tung Quang Nguyen ; 'Jon Maloy'
; tipc-discussion@lists.sourceforge.net;
ying@windriver.com
Cc: Mohan Krishna Ghanta Krishnamurthy
;
parthasarathy.bhuvara
ex. And
there is no more performance overhead (I will show it in another mail).
Actually, to achieve that (fix starvation issue), I believe we have to do 2
things as I did and the test result was good.
Best regards,
Tung Nguyen
-Original Message-
From: Jon Maloy
Sent: Wednesday, July 17, 2019
Hi David,
I compiled previous version and tested it. But I forgot to observe kernel
warning.
For the way to reproduce the issue: calling sendto() and printf() right
after that to print out a log to see if sendto() was successful. On some
occasions, the log was never printed and stack trace
com>
Sent: Tuesday, April 24, 2018 7:22 PM
To: tung quang nguyen <tung.q.ngu...@dektech.com.au>;
tipc-discussion@lists.sourceforge.net
Subject: Re: [tipc-discussion] tipc: remove skb_clone() in function
tipc_msg_extract()
First of all, please submit your patch with git send email command.
O
Function tipc_msg_extract() is using skb_clone() to clone
inner messages from bundle message. Although it is safe to
use this method, it has an undesired effect that each clone
inherits the true-size of the original buffer. As a result,
the clone almost always has to be copied by the message
47 matches
Mail list logo
