ssive, 0, key.pending);
tipc_crypto_key_detach(tx->aead[key.active], >lock);
- spin_unlock(>lock);
+ spin_unlock_bh(>lock);
pr_warn("%s: key is revoked\n", tx->name);
return -EKEYREVOKED;
Acked-by: Jon Maloy
__
(link_name[strnlen(link_name,
+ nla_len(attrs[TIPC_NLA_LINK_NAME]))] != '\0')
+ return -EINVAL;
+
err = -EINVAL;
if (!strcmp(link_name, tipc_bclink_name)) {
err = tipc_bclink_reset_stats(net, tipc_bc_sndlink(net));
Acked-by:
On 2023-06-22 09:30, Rune Torgersen wrote:
I can easily make it happen with known service addresses too.
We have shortlived processes that does a query:
Open 226 1
Send query to 226 2.
226 2 sends response back to 226 1. - Message gets dropped.
It is obviously a timing issue, - an unintended
: check the bearer min mtu properly when setting it by netlink
net/tipc/bearer.c| 17 +++--
net/tipc/bearer.h| 3 +++
net/tipc/link.c | 9 ++---
net/tipc/udp_media.c | 5 +++--
4 files changed, 27 insertions(+), 7 deletions(-)
Series
Acked-by: Jon Maloy
On 2023-05-03 09:35, Xin Long wrote:
On Tue, May 2, 2023 at 11:31 PM Tung Quang Nguyen
wrote:
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
On 2023-04-04 20:30, Jon Maloy wrote:
On 2023-03-16 12:03, Nagendra Kumar via tipc-discussion wrote:
Hi Jon/Tuong/Tung/Hoang/Thang,Is there any thoughts on the below
email trails??
Thanks-Nagendra
On Monday, 13 March, 2023 at 10:59:45 pm IST, Nagendra Kumar via
tipc-discussion
On 2023-03-16 12:03, Nagendra Kumar via tipc-discussion wrote:
Hi Jon/Tuong/Tung/Hoang/Thang,Is there any thoughts on the below email
trails??
Thanks-Nagendra
On Monday, 13 March, 2023 at 10:59:45 pm IST, Nagendra Kumar via tipc-discussion
wrote:
Sending it again.
On
On 2023-03-22 06:48, Ragavendran Sridharan wrote:
Hi Team,
I am requesting assistance onTIPC in linux. In our project we are using
Tipc version 2.02 version . We are facing the issue of TIPC connections
not getting establised and returning Error as :TIPC_ERR_NO_PORT from TIPC
Server.
Could
to TIPC to set up TIPC.
Thne I hope we can get some further.
Regards
Jon Maloy
On 2023-03-22 06:48, Ragavendran Sridharan wrote:
Hi Team,
I am requesting assistance onTIPC in linux. In our project we are using
Tipc version 2.02 version . We are facing the issue of TIPC connections
not getting
Hi Nagendra,
Sorry for not noticing this earlier. I will look into this next week.
///jon
On 2023-03-13 12:58, Nagendra Kumar via tipc-discussion wrote:
Sending it again.
On Friday, 10 March, 2023 at 11:49:59 am IST, Nagendra Kumar
wrote:
Hi,We are trying to use TIPC on
On 2023-02-05 23:11, Tung Quang Nguyen wrote:
-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
On 2023-01-31 23:03, Tung Nguyen wrote:
When sending a SYN message, this kernel stack trace is observed:
...
[ 13.396352] RIP: 0010:_copy_from_iter+0xb4/0x550
...
[ 13.398494] Call Trace:
[ 13.398630]
[ 13.398630] ? __alloc_skb+0xed/0x1a0
[ 13.398630] tipc_msg_build+0x12c/0x670
On 2023-01-06 15:51, Asebot Fasil Abebe wrote:
Hi folks,
I'd like to understand the expected behavior when a member of a group is
slow to pick up a group multicast/broadcast message. From what I'm
observing on my testing, it seem to slow down the whole messaging bus.
Please confirm and advise
)
+ if (reset && !link_is_reset)
tipc_node_link_down(n, b->identity, false);
tipc_node_put(n);
}
Acked-by: Jon Maloy
Nice job!
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
ire the messages to be presented to the
receiving side of the loopback device.
v3 - Function dev_nit_active used to check for network taps.
- Procedure netif_rx_ni used to send cloned messages to loopback
device.
Signed-off-by: John Rutherford
Acked-by: Jon Maloy
Ac
int err;
- skb_linearize(skb);
+ if (skb_linearize(skb)) {
+ kfree_skb(skb);
+ return;
+ }
hdr = buf_msg(skb);
if (caps & TIPC_NODE_ID128)
Acked-by: Jon Maloy
___
tipc-discussion mailing list
t
patch.
Xin Long (2):
tipc: set con sock in tipc_conn_alloc
tipc: add an extra conn_get in tipc_conn_alloc
net/tipc/topsrv.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
Series
Acked-by: Jon Maloy
___
tipc
dule_get(lsock->sk->sk_prot_creator->owner);
srv->listener = NULL;
spin_unlock_bh(>idr_lock);
- sock_release(lsock);
+
tipc_topsrv_work_stop(srv);
+ sock_release(lsock);
idr_destroy(>conn_idr);
kfree(srv);
}
Acked-by: Jon Maloy
_
u32 dtype;
- u32 node;
- unsigned long expires;
- struct list_head next;
-};
-
/**
* publ_to_item - add publication info to a publication message
* @p: publication info
Acked-by: Jon Maloy
___
tipc-discussion mailing
On 7/2/22 14:57, Christian Kohlschütter wrote:
Hi all,
I'm the author of junixsocket, an Open-Source Java library that, until
recently, focused on providing access to Unix domain sockets for Java 8 and
above.
It is my great delight to announce that with version 2.5, junixsocket adds
link_name, tipc_bclink_name)) {
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
peer->domain;
if (dom)
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>bc_entry.namedq, snd_l,
->bc_entry.link)) {
- pr_warn("Broadcast rcv link creation failed, no mem\n");
- tipc_node_write_unlock_fast(n);
-
On 6/16/22 06:26, Røysland, Jonas Gjendem via tipc-discussion wrote:
Hey,
We are working with the TIPC in the terminal and trying to connect a client and
a server between two different linux machines. We are using the programs
hello_client.c and hello_server.c to send and recieve to check
tipc_dest_push(struct list_head *l, u32 node, u32
port);
bool tipc_dest_pop(struct list_head *l, u32 *node, u32 *port);
bool tipc_dest_del(struct list_head *l, u32 node, u32 port);
void tipc_dest_list_purge(struct list_head *l);
-int tipc_dest_list_len(struct list_head *l);
#endif
Acked-by: Jon
Hi,
There are som drawings in the protocol spec too:
http://tipc.io/protocol.html#anchor53
Some of the info in this spec is obsolete, but this one is still correct.
Med vennlig hilsen
///jon
On 6/15/22 04:10, Hoang Huu Le wrote:
Hi,
Please take an example at:
On 6/13/22 00:00, Hoang Huu Le wrote:
Hi Jon, Ying,
Just remind in case you guys missed this email thread.
Yes, I had missed it. It looks good to me.
///jon
Thanks,
Hoang
-Original Message-
From: Hoang Le
Sent: Tuesday, June 7, 2022 2:35 PM
To: jma...@redhat.com;
Acked-by: Jon Maloy
On 5/26/22 07:02, Hoang Le wrote:
syzbot reported uninit-value:
=
BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]
BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725
string_nocheck
On 3/31/22 10:28, Paolo Abeni wrote:
On Tue, 2022-03-29 at 18:12 +0200, Niels Dossche wrote:
Currently, n->keepalive_intv is written to while n is locked by a read
lock instead of a write lock. This seems to me to break the atomicity
against other readers.
Change this to a write lock instead
/* We never set seq or call nl_dump_check_consistent()
* this means that setting prev_seq here will cause the
* consistence check to fail in the netlink callback
Acked-by: Jon Maloy
___
tipc-dis
On 1/11/22 18:01, Duzan, Gary D via tipc-discussion wrote:
Is there a reliable way for a process to determine if a TIPC socket address
points to an open socket without disturbing the target process? I'm hoping to
be able to determine the liveness/reachability of a datagram peer, at
ey_size(aead->key), GFP_ATOMIC);
rcu_read_unlock();
/* Now, generate new key, initiate & distribute it */
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
(skb)->decrypted) {
+ if (sysctl_tipc_key_exchange_enabled &&
+ TIPC_SKB_CB(skb)->decrypted) {
tipc_crypto_msg_rcv(l->net, skb);
return true;
}
Ac
r_err("TX: skb_cow_data() returned %d\n", nsg);
- return nsg;
- }
+ nsg = skb_cow_data(skb, tailen, );
+ if (unlikely(nsg < 0)) {
+ pr_err("TX: skb_cow_data() returned %d\n", nsg);
+ return nsg;
}
Acked-by: Jon Maloy
On 11/15/21 11:01, Tadeusz Struk wrote:
kmemdup can return a null pointer so need to check for it, otherwise
the null key will be dereferenced later in tipc_crypto_key_xmit as
can be seen in the trace [1].
Cc: Jon Maloy
Cc: Ying Xue
Cc: "David S. Miller"
You should mention that is a supplementary fix to CVE-2021-43267,
improving the original fix in commit
fa40d9734a57bcbfa79a280189799f76c88f7bb0 ("tipc: fix size validations
for the MSG_CRYPTO type")
///jon
On 11/14/21 08:09, Xue, Ying wrote:
Thanks Xin! The patch looks good to me.
Acked-by: Jon Maloy
On 11/14/21 08:09, Xue, Ying wrote:
Thanks Xin! The patch looks good to me.
Acked-by: Ying Xue
-Original Message-
From: Xin Long
Sent: Saturday, November 13, 2021 3:23 AM
To: tipc-discussion@lists.sourceforge.net
Subject: [tipc-discussion] [PATCH net] tipc: only
On 11/11/21 15:59, Tadeusz Struk wrote:
kmemdup can return a null pointer so need to check for it, otherwise
the null key will be dereferenced later in tipc_crypto_key_xmit as
can be seen in the trace [1].
Cc: Jon Maloy
Cc: Ying Xue
Cc: "David S. Miller"
Cc: Jakub Kicinsk
On 9/23/21 11:28, Andy Stec via tipc-discussion wrote:
The online documentation says that 'tipc node set address' command can be
omitted starting with kernel 4.17. But it doesn't say that it should be
replaced with 'tipc node set identity'. Based on that and based on my testing,
it
sock *sk,
u32 dport, struct sk_buff_head *xmitq)
{
- unsigned long time_limit = jiffies + 2;
+ unsigned long time_limit = jiffies + usecs_to_jiffies(2);
struct sk_buff *skb;
unsigned int lim;
atomic_t *dcnt;
Acked-by: Jon Maloy
On 06/07/2021 14:22, Xin Long wrote:
Since there's no enough bit in netdev_features_t for
NETIF_F_GSO_TIPC_BIT, and tipc is using the simliar
code as sctp, this patch will reuse SKB_GSO_SCTP and
NETIF_F_GSO_SCTP_BIT for tipc.
Signed-off-by: Xin Long
---
include/linux/skbuff.h | 2 --
On 06/07/2021 14:22, Xin Long wrote:
This patch is to receive and process the probe ack by checking
msg_max_pkt() == l->pl.probe_size then does state transition
in tipc_link_pl_recv().
For the details, see:
https://lwn.net/Articles/860385/
Signed-off-by: Xin Long
---
net/tipc/link.c
On 06/07/2021 14:22, Xin Long wrote:
This patchset is to implement PLPMTUD and GSO for TIPC,
Patch 1-5 are for PLPMTUD while 6-8 are for GSO.
I think this should be posted as two separate series, as they really
implement two different features.
The problem I see with this is that you
On 08/09/2021 19:10, Hoang Huu Le wrote:
-Original Message-
From: Jon Maloy
Sent: Thursday, September 9, 2021 5:42 AM
To: Hoang Huu Le ;
tipc-discussion@lists.sourceforge.net; Tung Quang Nguyen
; Xin Long ; Ying Xue
Cc: Huy Xuan Nhat Hoang
Subject: Re: Strange behavior
schedule. What are your views?
I assume your test was done with many, e.g. 100 connections?
///jon
Regards,
Hoang
-Original Message-
From: Jon Maloy
Sent: Wednesday, September 1, 2021 7:39 AM
To: Hoang Huu Le ;
tipc-discussion@lists.sourceforge.net; Tung Quang Nguyen
; Xin Long ; Ying
enjoy your vacation.
Our new team member (CCed) will take a look at it.
Regards,
Hoang
-Original Message-
From: Jon Maloy
Sent: Wednesday, July 28, 2021 6:20 AM
To: tipc-discussion@lists.sourceforge.net; Tung Quang Nguyen
; Hoang Huu Le
; Xin Long ; Ying Xue
Subject: Strange behavior
timeout = msecs_to_jiffies(timeout);
tipc_wait_for_connect(sock, );
}
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourc
kb_retransmit_time(skb, l);
--
2.30.2
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
I did by accident discover a strange behavior in the function
tipc_sk_enqueue:
static void tipc_sk_enqueue(struct sk_buff_head *inputq,
struct sock *sk, u32 dport,
struct sk_buff_head *xmitq)
{
struct tipc_sock *tsk = tipc_sk(sk);
Allocate memory for the AEAD operation */
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
did not show up in my RH mailbox.Anyway,Acked-by: Jon
Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
___
tipc-dis
_tipc_sendstream(new_sock, , 0);
release_sock(new_sk);
exit:
release_sock(sk);
Acked by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
l_pending(current))
break;
}
- finish_wait(sk_sleep(sk), );
return err;
}
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
On 7/5/21 11:57 PM, maloy wrote:
Sent from my Galaxy
Original message
From: Xin Long
Date: 2021-06-30 20:21 (GMT-05:00)
To: Jon Maloy , Erin Shepherd
, tipc-discussion@lists.sourceforge.net
Subject: [tipc-discussion] [PATCHv2 net-next] tipc: keep the skb in
rcv queue
On 29/06/2021 16:10, Erin Shepherd wrote:
Jon Maloy writes:
In the latter case we would be on the 100% safe side, although I have a
real hard time to see that this could be a real issue. Why would anybody
deliberately design an application for having messages truncated.
My concern would
On 29/06/2021 17:41, Xin Long wrote:
On Tue, Jun 29, 2021 at 3:57 PM Jon Maloy wrote:
[...]
Yes, Jon, I mean the opposite.
when MSG_EOR is set, we will go with what this patch does,
but to delete MSG_EOR if this is not the last part of the data,
and keep MSG_EOR if this is the last part
On 11/06/2021 17:33, Xin Long wrote:
kernel-doc for TIPC is too simple, we need to add more information for it.
This patch is to extend the abstract, and add the Features and Links items.
Signed-off-by: Xin Long
Acked-by: Jon Maloy
---
Documentation/networking/tipc.rst | 121
On 28/06/2021 15:16, Xin Long wrote:
On Mon, Jun 28, 2021 at 3:03 PM Xin Long wrote:
On Sun, Jun 27, 2021 at 3:44 PM Erin Shepherd wrote:
Xin Long writes:
Currently, when userspace reads a datagram with a buffer that is
smaller than this datagram, the data will be truncated and only
part
y, and assign the calculation
directly to one_page_mtu below.
Otherwise:
Acked-by: Jon Maloy
+const int one_page_mtu = ONE_PAGE_SKB_SZ;
+
static unsigned int align(unsigned int i)
{
return (i + 3) & ~3u;
@@ -69,13 +74,8 @@ static unsigned int align(unsigned int i)
struct sk_buff
On 6/15/21 5:45 AM, menglong8.d...@gmail.com wrote:
From: Menglong Dong
FB_MTU is used in 'tipc_msg_build()' to alloc smaller skb when memory
allocation fails, which can avoid unnecessary sending failures.
The value of FB_MTU now is 3744, and the data size will be:
(3744 +
-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 v2 net-next 0/2] net: tipc: fix FB_MTU eat two pages and do
some code cleanup
On 6
On 6/9/21 8:56 AM, Menglong Dong wrote:
On Wed, Jun 9, 2021 at 6:47 PM Jon Maloy wrote:
On 6/9/21 6:32 AM, menglong8.d...@gmail.com wrote:
From: Menglong Dong
In the first patch, FB_MTU is redefined to make sure data size will not
exceed PAGE_SIZE. Besides, I removed the alignment
GT.M Core
*From:* Duzan, Gary D via tipc-discussion
*Sent:* Thursday, June 3, 2021 10:57 AM
*To:* Jon Maloy ; Xin Long
*Cc:* tipc-discussion@lists.sourceforge.net
*Subject:* Re: [tipc-discussion] EXTERNAL: Re: DGRAM/STREAM Crossover
on Debian?
I can frankly admit that this is a proble
On 6/9/21 6:32 AM, menglong8.d...@gmail.com wrote:
From: Menglong Dong
In the first patch, FB_MTU is redefined to make sure data size will not
exceed PAGE_SIZE. Besides, I removed the alignment for buf_size in
tipc_buf_acquire, because skb_alloc_fclone will do the alignment job.
In the
On 6/8/21 10:54 PM, Menglong Dong wrote:
On Tue, Jun 08, 2021 at 06:37:38PM -0400, Jon Maloy wrote:
[...]
I spent a little more time looking into this. I think the best we can do is
to keep FB_MTU internal to msg.c, and then add an outline function to msg.c
that can be used by bcast.c
On 6/7/21 8:51 AM, Menglong Dong wrote:
On Sat, Jun 05, 2021 at 10:25:53AM -0400, Jon Maloy wrote:
On 6/4/21 9:28 PM, Menglong Dong wrote:
Hello Maloy,
On Sat, Jun 5, 2021 at 3:20 AM Jon Maloy wrote:
[...]
So if I use the non-crypto version, the size allocated will be:
PAGE_SIZE
On 6/4/21 9:28 PM, Menglong Dong wrote:
Hello Maloy,
On Sat, Jun 5, 2021 at 3:20 AM Jon Maloy wrote:
[...]
Please don't add any extra file just for this little fix. We have enough
files.
Keep the macros in msg.h/c where they used to be. You can still add
your copyright line to those
On 6/4/21 3:44 AM, menglong8.d...@gmail.com wrote:
From: Menglong Dong
FB_MTU is used in 'tipc_msg_build()' to alloc smaller skb when memory
allocation fails, which can avoid unnecessary sending failures.
The value of FB_MTU now is 3744, and the data size will be:
(3744 +
g us aware of this.
///jon
----
*From:* Jon Maloy
*Sent:* Wednesday, June 2, 2021 8:56 PM
*To:* Xin Long ; Duzan, Gary D
*Cc:* tipc-discussion@lists.sourceforge.net
*Subject:* EXTERNAL: Re: [tipc-discussion] DGRAM/STREAM
t:
commit 25b9221b959483f17c2964d0922869e16caa86b5
Author: Jon Maloy
Date: Fri Sep 28 20:23:21 2018 +0200
tipc: add SYN bit to connection setup messages
The SYN msg for STREAM is no different from the DATA msg for DGRAM.
that's what you're seeing in kernel-4.19
Debian isn't a targe
584 bytes, not 3744.
Feel free to post a patch for this if you want to.
Thanks
///Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
CB(head)->tail = tail;
- }
- } else {
- skb_frag_list_init(head);
- }
return 0;
}
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lis
= tipc_net(net);
-
- tn->final_work.net = net;
- tn->final_work.addr = addr;
- schedule_work(>final_work.work);
+ tipc_net_finalize(tipc_link_net(tn->bcl), tn->trial_addr);
}
void tipc_net_stop(struct net *net)
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
one outside of rtnl lock */
+ atomic_inc(_net(sock_net(ub->ubsock->sk))->wq_count);
INIT_WORK(>work, cleanup_bearer);
schedule_work(>work);
}
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc
On 5/15/21 11:58 AM, Xin Long wrote:
On Fri, May 14, 2021 at 7:18 PM Jon Maloy wrote:
On 5/14/21 6:10 PM, patchwork-bot+netdev...@kernel.org wrote:
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Fri, 14 May 2021 08:23:03 +0700 you wrote:
This reverts commit
ight still be an issue.
Does anybody have a theory?
///jon
Fixes: 6bf24dc0cc0c ("net:tipc: Fix a double free in tipc_sk_mcast_rcv")
Acked-by: Jon Maloy
Acked-by: Tung Nguyen
Signed-off-by: Hoang Le
[...]
Here is the summary with links:
- [net] Revert "net:tipc: Fix a double
On 5/14/21 11:42 AM, Xin Long wrote:
On Thu, May 13, 2021 at 5:15 PM Jon Maloy wrote:
On 4/28/21 3:30 PM, Xin Long wrote:
After commit cb1b728096f5 ("tipc: eliminate race condition at multicast
reception"), when processing the multicast reception, the packets are
firstly
On 4/28/21 3:30 PM, Xin Long wrote:
After commit cb1b728096f5 ("tipc: eliminate race condition at multicast
reception"), when processing the multicast reception, the packets are
firstly moved from be->inputq1 to be->arrvq in tipc_node_broadcast(),
then process be->arrvq in
mnlu_gen_socket_close(_nlg);
return -1;
}
@@ -57,7 +68,9 @@ static int publ_list(uint32_t sock)
mnl_attr_put_u32(nlh, TIPC_NLA_SOCK_REF, sock);
mnl_attr_nest_end(nlh, nest);
- return msg_dumpit(nlh, publ_list_cb, NULL);
+
+13,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include "mnl_utils.h"
#include "bearer.h"
#include "link.h"
#include "nametable.h"
@@ -26,6 +30,7 @@
int help_flag;
int json;
+struct mnlu_gen_socke
AX_BEARERS;
+ with_this_prio = 1;
}
- pr_warn("Bearer <%s>: trying with adjusted priority\n", name);
- prio--;
- bearer_id = 0;
- with_this_prio = 1;
}
if (bearer_id >= MAX_BEARERS) {
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
perror("error");
mnl_socket_close(nl);
Acked-by: Jon Maloy
Thanks, Hoang.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
return -EINVAL;
+ }
#ifdef CONFIG_TIPC_MEDIA_UDP
if (tipc_udp_mtu_bad(nla_get_u32
-(props[TIPC_NLA_PROP_MTU])))
+(props[TIPC_NLA_PROP_M
hes.
Thanks.
On Wed, Dec 9, 2020 at 2:51 AM wrote:
From: Jon Maloy
We make a number of simplifications and cleanups, especially to call signatures
in the binding table. This makes the code easier to understand and serves as a
preparation for an upcoming functional addition.
Jon Maloy (16):
t
Hi Hoang,
I noticed that this series is not upstream yet. Did I forget to ack it?
Series
Acked-by: Jon Maloy
On 1/18/21 3:08 AM, Hoang Huu Le wrote:
From: Hoang Le
(struct tipc_link_info)->dest is in network order (__be32), so we must
convert the value to network order before assign
Tung Quang Nguyen ; Hoang Huu Le
; Tuong Tong Lien ;
jma...@redhat.com; ma...@donjonn.com; x...@redhat.com; ying@windriver.com;
parthasarathy.bhuvara...@gmail.com
Subject: [net-next 01/16] tipc: re-organize members of struct publication
From: Jon Maloy
In a future commit we will introduce mo
> SHORT_H_SIZE) {
- msg_set_orignode(msg, onode);
- msg_set_destnode(msg, dnode);
- }
return buf;
}
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
ht
/net/tipc/netlink_compat.c
@@ -696,7 +696,7 @@ static int tipc_nl_compat_link_dump(struct
tipc_nl_compat_msg *msg,
if (err)
return err;
- link_info.dest = nla_get_flag(link[TIPC_NLA_LINK_DEST]);
+ link_info.dest = htonl(nla_get_flag(link[TIPC_NLA_LIN
* @dnode: address of destination node
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
On 1/11/21 9:20 AM, Xue, Ying wrote:
- seq = >addr.nameseq;
- if (dest->addrtype == TIPC_ADDR_MCAST)
- return tipc_sendmcast(sock, seq, m, dlen, timeout);
-
- if (dest->addrtype == TIPC_SERVICE_ADDR) {
- type = dest->addr.name.name.type;
-
if (imp == TIPC_SYSTEM_IMPORTANCE) {
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
suspect that the VMware virtual
network configuration is squashing non-IP traffic, so I'm focusing on that
angle.
Gary Duzan
From: Jon Maloy
Sent: Monday, January 4, 2021 8:01 PM
To: Duzan, Gary D ;
tipc
don't discover each other, check the
cluster id (aka network id) by doing 'tipc node get netid' on both sides.
If the interfaces don't have IP addresses you could assign those
temporarily, just to check.
What do the commands 'tipc link list' and 'tipc bearer list' show you?
BR
Jon Maloy
On 1/4
oto err_out;
+ }
do {
int rem;
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Hi Hoang,
This was the one I had in mind. To me it looks like we still have a problem.
///jon
Forwarded Message
Subject:Re: BUG: rwlock bad magic on CPU, kworker/0:LINE/NUM, ADDR
Date: Mon, 30 Nov 2020 12:35:30 +0100
From: Dmitry Vyukov
To: syzbot
CC: David
de(net, addr))
return -ENOTSUPP;
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
s/incompatiable/incompatible
Still acked
///jon
On 11/27/20 10:14 AM, Jon Maloy wrote:
On 11/27/20 12:01 AM, Hoang Huu Le wrote:
From: Hoang Le
In commit 682cd3cf946b6
("tipc: confgiure and apply UDP bearer MTU on running links"), we
introduced a function to change UDP
tipc_bearer_xmit(net, bearer_id, , >maddr, NULL);
}
Acked-by: Jon Maloy
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Hi Holger,
We will look into this. It is a new setup for us, so it has to be
prepared first.
///jon
On 11/19/20 9:33 AM, Holger Brunck wrote:
Hi all,
we have currently problems with TIPC in combination with a TAP interface and
fragmented
messages. We have a Kirkwood board getting TIPC
tood its expected behavior.
We will look into this.
On a different note, you could instead omit the bond interface and try
using dual TIPC links, which work in active-active mode and give better
performance.
Is that an option for you?
BR
Jon Maloy
On 11/19/20 11:36 PM, Howard Finer wrote:
I am t
1 - 100 of 969 matches
Mail list logo
