Re: [tipc-discussion] [PATCH net-next] net: tipc: Fix spelling errors in net/tipc module
From: Zheng Yongjun Date: Tue, 6 Apr 2021 23:19:09 +0800 > These patches fix a series of spelling errors in net/tipc module. > > Reported-by: Hulk Robot > Signed-off-by: Zheng Yongjun This does not apply to net-next, please respin. Thanks. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] net: tipc: prevent possible null deref of link
From: Cengiz Can Date: Mon, 7 Dec 2020 11:14:24 +0300 > `tipc_node_apply_property` does a null check on a `tipc_link_entry` > pointer but also accesses the same pointer out of the null check block. > > This triggers a warning on Coverity Static Analyzer because we're > implying that `e->link` can BE null. > > Move "Update MTU for node link entry" line into if block to make sure > that we're not in a state that `e->link` is null. > > Signed-off-by: Cengiz Can > --- Applied, thanks., ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] net: tipc: Supply missing udp_media.h include file
From: Wang Hai Date: Fri, 18 Sep 2020 21:18:19 +0800 > If the header file containing a function's prototype isn't included by > the sourcefile containing the associated function, the build system > complains of missing prototypes. > > Fixes the following W=1 kernel build warning(s): > > net/tipc/udp_media.c:446:5: warning: no previous prototype for > ‘tipc_udp_nl_dump_remoteip’ [-Wmissing-prototypes] > net/tipc/udp_media.c:532:5: warning: no previous prototype for > ‘tipc_udp_nl_add_bearer_data’ [-Wmissing-prototypes] > net/tipc/udp_media.c:614:5: warning: no previous prototype for > ‘tipc_udp_nl_bearer_add’ [-Wmissing-prototypes] > > Signed-off-by: Wang Hai Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] tipc: Remove unused macro CF_SERVER
From: YueHaibing Date: Fri, 18 Sep 2020 21:16:15 +0800 > It is no used any more, so can remove it. > > Signed-off-by: YueHaibing Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v3 0/4] tipc: add more features to TIPC encryption
From: Tuong Lien
Date: Fri, 18 Sep 2020 08:17:25 +0700
> This series adds some new features to TIPC encryption:
>
> - Patch 1 ("tipc: optimize key switching time and logic") optimizes the
> code and logic in preparation for the following commits.
>
> - Patch 2 ("tipc: introduce encryption master key") introduces support
> of 'master key' for authentication of new nodes and key exchange. A
> master key can be set/changed by user via netlink (eg. using the same
> 'tipc node set key' command in iproute2/tipc).
>
> - Patch 3 ("tipc: add automatic session key exchange") allows a session
> key to be securely exchanged between nodes as needed.
>
> - Patch 4 ("tipc: add automatic rekeying for encryption key") adds
> automatic 'rekeying' of session keys a specific interval. The new key
> will be distributed automatically to peer nodes, so become active then.
> The rekeying interval is configurable via netlink as well.
>
> v2: update the "tipc: add automatic session key exchange" patch to fix
> "implicit declaration" issue when built without "CONFIG_TIPC_CRYPTO".
>
> v3: update the patches according to David comments by using the
> "genl_info->extack" for messages in response to netlink user config
> requests.
Series applied, thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] net: tipc: kerneldoc fixes
From: Lu Wei
Date: Tue, 15 Sep 2020 10:39:55 +0800
> Fix parameter description of tipc_link_bc_create()
>
> Reported-by: Hulk Robot
> Fixes: 16ad3f4022bb ("tipc: introduce variable window congestion control")
> Signed-off-by: Lu Wei
Applied, thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: use skb_unshare() instead in tipc_buf_append()
From: Xin Long
Date: Sun, 13 Sep 2020 19:37:31 +0800
> In tipc_buf_append() it may change skb's frag_list, and it causes
> problems when this skb is cloned. skb_unclone() doesn't really
> make this skb's flag_list available to change.
>
> Shuang Li has reported an use-after-free issue because of this
> when creating quite a few macvlan dev over the same dev, where
> the broadcast packets will be cloned and go up to the stack:
...
> So fix it by using skb_unshare() instead, which would create a new
> skb for the cloned frag and it'll be safe to change its frag_list.
> The similar things were also done in sctp_make_reassembled_event(),
> which is using skb_copy().
>
> Reported-by: Shuang Li
> Fixes: 37e22164a8a3 ("tipc: rename and move message reassembly function")
> Signed-off-by: Xin Long
Applied and queued up for -stable, thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] tipc: fix shutdown() of connection oriented socket
From: Tetsuo Handa
Date: Sat, 5 Sep 2020 15:14:47 +0900
> I confirmed that the problem fixed by commit 2a63866c8b51a3f7 ("tipc: fix
> shutdown() of connectionless socket") also applies to stream socket.
>
> --
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> int fds[2] = { -1, -1 };
> socketpair(PF_TIPC, SOCK_STREAM /* or SOCK_DGRAM */, 0, fds);
> if (fork() == 0)
> _exit(read(fds[0], NULL, 1));
> shutdown(fds[0], SHUT_RDWR); /* This must make read() return. */
> wait(NULL); /* To be woken up by _exit(). */
> return 0;
> }
> --
>
> Since shutdown(SHUT_RDWR) should affect all processes sharing that socket,
> unconditionally setting sk->sk_shutdown to SHUTDOWN_MASK will be the right
> behavior.
>
> Signed-off-by: Tetsuo Handa
Applied and queued up for -stable, thank you.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] tipc: fix shutdown() of connectionless socket
From: Wouter Verhelst Date: Thu, 3 Sep 2020 14:05:15 +0200 > That's fine, because NBD doesn't deal with SOCK_DGRAM sockets anyway > (i.e., passing a SOCK_DGRAM socket to the NBD device is undefined > behavior). Then why doesn't NBD simply reject such sockets? ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v2 1/4] tipc: optimize key switching time and logic
From: Tuong Tong Lien Date: Wed, 2 Sep 2020 06:16:44 + > Yes, the netlink extack message is fine but the fact is that we > currently do not obtain such message from the user space tool > (i.e. iproute2/tipc). So, if really needed, we will have to update > the tool as well... For now, I will remove all the message logs as > it is fine enough with the return code. Please convert the messages to extack as I requested from you. Until then, you'll have no incentive to fix the tool. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v2 1/4] tipc: optimize key switching time and logic
From: Tuong Lien
Date: Mon, 31 Aug 2020 15:38:14 +0700
> We reduce the lasting time for a pending TX key to be active as well as
> for a passive RX key to be freed which generally helps speed up the key
> switching. It is not expected to be too fast but should not be too slow
> either. Also the key handling logic is simplified that a pending RX key
> will be removed automatically if it is found not working after a number
> of times; the probing for a pending TX key is now carried on a specific
> message user ('LINK_PROTOCOL' or 'LINK_CONFIG') which is more efficient
> than using a timer on broadcast messages, the timer is reserved for use
> later as needed.
>
> The kernel logs or 'pr***()' are now made as clear as possible to user.
> Some prints are added, removed or changed to the debug-level. The
> 'TIPC_CRYPTO_DEBUG' definition is removed, and the 'pr_debug()' is used
> instead which will be much helpful in runtime.
>
> Besides we also optimize the code in some other places as a preparation
> for later commits.
>
> This commit does not change the en/decryption functionalities.
>
> Acked-by: Jon Maloy
> Signed-off-by: Tuong Lien
Random log messages in response to user config requests are
inappropriate especially with netlink.
Report such informational responses to errors using the
genl_info->extack instead, as is standard practice across
the entire kernel.
Please remove all kernel log messages that get emitted due to
netlink operations and use extack notifications instead.
I also disagree with the commit message stating:
This commit does not change the en/decryption functionalities.
You are changing timer lengths and other aspects of crypto behavior,
so the patch is in fact changing things.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] tipc: Remove unused macro TIPC_NACK_INTV
From: YueHaibing Date: Sat, 29 Aug 2020 19:52:14 +0800 > There is no caller in tree any more. > > Signed-off-by: YueHaibing Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] tipc: Remove unused macro TIPC_FWD_MSG
From: YueHaibing Date: Sat, 29 Aug 2020 19:50:26 +0800 > There is no caller in tree any more. > > Signed-off-by: YueHaibing Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix using smp_processor_id() in preemptible
From: Tuong Lien
Date: Sun, 30 Aug 2020 02:37:55 +0700
> The 'this_cpu_ptr()' is used to obtain the AEAD key' TFM on the current
> CPU for encryption, however the execution can be preemptible since it's
> actually user-space context, so the 'using smp_processor_id() in
> preemptible' has been observed.
>
> We fix the issue by using the 'get/put_cpu_ptr()' API which consists of
> a 'preempt_disable()' instead.
>
> Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
> Acked-by: Jon Maloy
> Signed-off-by: Tuong Lien
Applied and queued up for -stable.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: call rcu_read_lock() in tipc_aead_encrypt_done()
From: Xin Long
Date: Thu, 20 Aug 2020 15:34:47 +0800
> b->media->send_msg() requires rcu_read_lock(), as we can see
> elsewhere in tipc, tipc_bearer_xmit, tipc_bearer_xmit_skb
> and tipc_bearer_bc_xmit().
>
> Syzbot has reported this issue as:
>
> net/tipc/bearer.c:466 suspicious rcu_dereference_check() usage!
> Workqueue: cryptd cryptd_queue_worker
> Call Trace:
>tipc_l2_send_msg+0x354/0x420 net/tipc/bearer.c:466
>tipc_aead_encrypt_done+0x204/0x3a0 net/tipc/crypto.c:761
>cryptd_aead_crypt+0xe8/0x1d0 crypto/cryptd.c:739
>cryptd_queue_worker+0x118/0x1b0 crypto/cryptd.c:181
>process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
>worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
>kthread+0x3b5/0x4a0 kernel/kthread.c:291
>ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
>
> So fix it by calling rcu_read_lock() in tipc_aead_encrypt_done()
> for b->media->send_msg().
>
> Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
> Reported-by: syzbot+47bbc6b678d317ccc...@syzkaller.appspotmail.com
> Signed-off-by: Xin Long
Applied and queued up for -stable, thank you.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] ipv6: some fixes for ipv6_dev_find()
From: Xin Long
Date: Mon, 17 Aug 2020 14:30:49 +0800
> This patch is to do 3 things for ipv6_dev_find():
>
> As David A. noticed,
>
> - rt6_lookup() is not really needed. Different from __ip_dev_find(),
> ipv6_dev_find() doesn't have a compatibility problem, so remove it.
>
> As Hideaki suggested,
>
> - "valid" (non-tentative) check for the address is also needed.
> ipv6_chk_addr() calls ipv6_chk_addr_and_flags(), which will
> traverse the address hash list, but it's heavy to be called
> inside ipv6_dev_find(). This patch is to reuse the code of
> ipv6_chk_addr_and_flags() for ipv6_dev_find().
>
> - dev parameter is passed into ipv6_dev_find(), as link-local
> addresses from user space has sin6_scope_id set and the dev
> lookup needs it.
>
> Fixes: 81f6cb31222d ("ipv6: add ipv6_dev_find()")
> Suggested-by: YOSHIFUJI Hideaki
> Reported-by: David Ahern
> Signed-off-by: Xin Long
Applied, thank you.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] net: tipc: Convert to use the preferred fallthrough macro
From: Miaohe Lin Date: Tue, 18 Aug 2020 08:07:13 -0400 > Convert the uses of fallthrough comments to fallthrough macro. > > Signed-off-by: Miaohe Lin Applied to net-next. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: not enable tipc when ipv6 works as a module
From: Cong Wang Date: Mon, 17 Aug 2020 13:59:46 -0700 > Is this a new Kconfig feature? ipv6_stub was introduced for > VXLAN, at that time I don't remember we have such kind of > Kconfig rules, otherwise it would not be needed. The ipv6_stub exists in order to allow the troublesome "ipv6=m && feature_using_ipv6=y" combination. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: not enable tipc when ipv6 works as a module
From: Cong Wang Date: Mon, 17 Aug 2020 13:29:40 -0700 > On Mon, Aug 17, 2020 at 12:55 PM Randy Dunlap wrote: >> >> TIPC=m and IPV6=m builds just fine. >> >> Having tipc autoload ipv6 is a different problem. (IMO) >> >> >> This Kconfig entry: >> menuconfig TIPC >> tristate "The TIPC Protocol" >> depends on INET >> + depends on IPV6 || IPV6=n >> >> says: >> If IPV6=n, TIPC can be y/m/n. >> If IPV6=y/m, TIPC is limited to whatever IPV6 is set to. > > Hmm, nowadays we _do_ have IPV6=y on popular distros. > So this means TIPC would have to be builtin after this patch?? Note the word "limited", ipv6=y allows y and m, ipv6=m (more limited) allows only m. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: not enable tipc when ipv6 works as a module
From: Cong Wang Date: Mon, 17 Aug 2020 11:55:55 -0700 > On Mon, Aug 17, 2020 at 11:49 AM Randy Dunlap wrote: >> >> It just restricts how TIPC can be built, so that >> TIPC=y and IPV6=m cannot happen together, which causes >> a build error. > > It also disallows TIPC=m and IPV6=m, right? That combination is allowed. The whole "X || X=n" construct means X must be off or equal to the value of the Kconfig entry this dependency is for. Thus you'll see "depends IPV6 || IPV6=n" everywhere. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: not enable tipc when ipv6 works as a module
From: Xin Long
Date: Sun, 16 Aug 2020 17:32:03 +0800
> When using ipv6_dev_find() in one module, it requires ipv6 not to
> work as a module. Otherwise, this error occurs in build:
>
> undefined reference to `ipv6_dev_find'.
>
> So fix it by adding "depends on IPV6 || IPV6=n" to tipc/Kconfig,
> as it does in sctp/Kconfig.
>
> Fixes: 5a6f6f579178 ("tipc: set ub->ifindex for local ipv6 address")
> Reported-by: kernel test robot
> Acked-by: Randy Dunlap
> Signed-off-by: Xin Long
Applied.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net 0/2] net: fix a mcast issue for tipc udp media
From: Xin Long Date: Mon, 3 Aug 2020 23:34:45 +0800 > Patch 1 is to add a function to get the dev by source address, > whcih will be used by Patch 2. Series applied, thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] tipc: Use is_broadcast_ether_addr() instead of memcmp()
From: Huang Guobin Date: Sun, 2 Aug 2020 22:00:55 -0400 > Using is_broadcast_ether_addr() instead of directly use > memcmp() to determine if the ethernet address is broadcast > address. > > spatch with a semantic match is used to found this problem. > (http://coccinelle.lip6.fr/) > > Signed-off-by: Huang Guobin Applied, thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net v1 1/1] tipc: allow to build NACK message in link timeout function
From: Tung Nguyen
Date: Tue, 21 Jul 2020 08:57:05 +0700
> Commit 02288248b051 ("tipc: eliminate gap indicator from ACK messages")
> eliminated sending of the 'gap' indicator in regular ACK messages and
> only allowed to build NACK message with enabled probe/probe_reply.
> However, necessary correction for building NACK message was missed
> in tipc_link_timeout() function. This leads to significant delay and
> link reset (due to retransmission failure) in lossy environment.
>
> This commit fixes it by setting the 'probe' flag to 'true' when
> the receive deferred queue is not empty. As a result, NACK message
> will be built to send back to another peer.
>
> Fixes: commit 02288248b051 ("tipc: eliminate gap indicator from ACK messages")
"commit" doesn't belong here, I removed it when I applied your patch.
> Acked-by: Jon Maloy
> Signed-off-by: Tung Nguyen
Applied and queued up for -stable, thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH][next] tipc: Use struct_size() helper
From: "Gustavo A. R. Silva" Date: Thu, 18 Jun 2020 08:35:00 -0500 > Make use of the struct_size() helper instead of an open-coded version > in order to avoid any potential type mistakes. > > This code was detected with the help of Coccinelle and, audited and > fixed manually. > > Signed-off-by: Gustavo A. R. Silva Applied, thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix kernel WARNING in tipc_msg_append()
From: Tuong Lien
Date: Thu, 11 Jun 2020 17:07:35 +0700
> syzbot found the following issue:
>
> WARNING: CPU: 0 PID: 6808 at include/linux/thread_info.h:150 check_copy_size
> include/linux/thread_info.h:150 [inline]
> WARNING: CPU: 0 PID: 6808 at include/linux/thread_info.h:150 copy_from_iter
> include/linux/uio.h:144 [inline]
> WARNING: CPU: 0 PID: 6808 at include/linux/thread_info.h:150
> tipc_msg_append+0x49a/0x5e0 net/tipc/msg.c:242
> Kernel panic - not syncing: panic_on_warn set ...
>
> This happens after commit 5e9eeccc58f3 ("tipc: fix NULL pointer
> dereference in streaming") that tried to build at least one buffer even
> when the message data length is zero... However, it now exposes another
> bug that the 'mss' can be zero and the 'cpy' will be negative, thus the
> above kernel WARNING will appear!
> The zero value of 'mss' is never expected because it means Nagle is not
> enabled for the socket (actually the socket type was 'SOCK_SEQPACKET'),
> so the function 'tipc_msg_append()' must not be called at all. But that
> was in this particular case since the message data length was zero, and
> the 'send <= maxnagle' check became true.
>
> We resolve the issue by explicitly checking if Nagle is enabled for the
> socket, i.e. 'maxnagle != 0' before calling the 'tipc_msg_append()'. We
> also reinforce the function to against such a negative values if any.
>
> Reported-by: syzbot+75139a7d2605236b0...@syzkaller.appspotmail.com
> Fixes: c0bceb97db9e ("tipc: add smart nagle feature")
> Acked-by: Jon Maloy
> Signed-off-by: Tuong Lien
Applied and queued up for v5.5+ -stable.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix NULL pointer dereference in tipc_disc_rcv()
From: Tuong Lien Date: Thu, 11 Jun 2020 17:08:08 +0700 > When a bearer is enabled, we create a 'tipc_discoverer' object to store > the bearer related data along with a timer and a preformatted discovery > message buffer for later probing... However, this is only carried after > the bearer was set 'up', that left a race condition resulting in kernel > panic. > > It occurs when a discovery message from a peer node is received and > processed in bottom half (since the bearer is 'up' already) just before > the discoverer object is created but is now accessed in order to update > the preformatted buffer (with a new trial address, ...) so leads to the > NULL pointer dereference. > > We solve the problem by simply moving the bearer 'up' setting to later, > so make sure everything is ready prior to any message receiving. > > Acked-by: Jon Maloy > Signed-off-by: Tuong Lien Applied, thanks. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: update a binding service via broadcast
net-next is CLOSED, thank you ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: fix NULL pointer dereference in streaming
From: Tuong Lien
Date: Wed, 3 Jun 2020 12:06:01 +0700
> syzbot found the following crash:
...
> Call Trace:
> tipc_sendstream+0x4c/0x70 net/tipc/socket.c:1533
> sock_sendmsg_nosec net/socket.c:652 [inline]
> sock_sendmsg+0xcf/0x120 net/socket.c:672
> sys_sendmsg+0x32f/0x810 net/socket.c:2352
> ___sys_sendmsg+0x100/0x170 net/socket.c:2406
> __sys_sendmmsg+0x195/0x480 net/socket.c:2496
> __do_sys_sendmmsg net/socket.c:2525 [inline]
> __se_sys_sendmmsg net/socket.c:2522 [inline]
> __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2522
> do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> entry_SYSCALL_64_after_hwframe+0x49/0xb3
> RIP: 0033:0x440199
> ...
>
> This bug was bisected to commit 0a3e060f340d ("tipc: add test for Nagle
> algorithm effectiveness"). However, it is not the case, the trouble was
> from the base in the case of zero data length message sending, we would
> unexpectedly make an empty 'txq' queue after the 'tipc_msg_append()' in
> Nagle mode.
>
> A similar crash can be generated even without the bisected patch but at
> the link layer when it accesses the empty queue.
>
> We solve the issues by building at least one buffer to go with socket's
> header and an optional data section that may be empty like what we had
> with the 'tipc_msg_build()'.
>
> Note: the previous commit 4c21daae3dbc ("tipc: Fix NULL pointer
> dereference in __tipc_sendstream()") is obsoleted by this one since the
> 'txq' will be never empty and the check of 'skb != NULL' is unnecessary
> but it is safe anyway.
>
> Reported-by: syzbot+8eac6d030e7807c21...@syzkaller.appspotmail.com
> Fixes: c0bceb97db9e ("tipc: add smart nagle feature")
> Acked-by: Jon Maloy
> Signed-off-by: Tuong Lien
Applied and queued up for -stable, thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] tipc: Fix NULL pointer dereference in __tipc_sendstream()
From: YueHaibing
Date: Thu, 28 May 2020 22:34:07 +0800
> tipc_sendstream() may send zero length packet, then tipc_msg_append()
> do not alloc skb, skb_peek_tail() will get NULL, msg_set_ack_required
> will trigger NULL pointer dereference.
>
> Reported-by: syzbot+8eac6d030e7807c21...@syzkaller.appspotmail.com
> Fixes: 0a3e060f340d ("tipc: add test for Nagle algorithm effectiveness")
> Signed-off-by: YueHaibing
I spent some time reading this a few times and the Fixes: commit and
this change looks ok to me so I'm just going to apply this.
Thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] tipc: Fix NULL pointer dereference in __tipc_sendstream()
From: YueHaibing
Date: Thu, 28 May 2020 22:34:07 +0800
> tipc_sendstream() may send zero length packet, then tipc_msg_append()
> do not alloc skb, skb_peek_tail() will get NULL, msg_set_ack_required
> will trigger NULL pointer dereference.
>
> Reported-by: syzbot+8eac6d030e7807c21...@syzkaller.appspotmail.com
> Fixes: 0a3e060f340d ("tipc: add test for Nagle algorithm effectiveness")
> Signed-off-by: YueHaibing
Can a TIPC expert please review this?
Thank you.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] tipc: remove set but not used variable 'prev'
From: YueHaibing
Date: Thu, 28 May 2020 07:43:59 +
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> net/tipc/msg.c: In function 'tipc_msg_append':
> net/tipc/msg.c:215:24: warning:
> variable 'prev' set but not used [-Wunused-but-set-variable]
>
> commit 0a3e060f340d ("tipc: add test for Nagle algorithm effectiveness")
> left behind this, remove it.
>
> Signed-off-by: YueHaibing
Applied.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 0/5] tipc: add some improvements
From: Tuong Lien Date: Tue, 26 May 2020 16:38:33 +0700 > This series adds some improvements to TIPC. > > The first patch improves the TIPC broadcast's performance with the 'Gap > ACK blocks' mechanism similar to unicast before, while the others give > support on tracing & statistics for broadcast links, and an alternative > to carry broadcast retransmissions via unicast which might be useful in > some cases. > > Besides, the Nagle algorithm can now automatically 'adjust' itself > depending on the specific network condition a stream connection runs by > the last patch. Series applied, thanks. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net 0/3] tipc: add some patches
From: Tuong Lien Date: Wed, 13 May 2020 19:33:15 +0700 > This series adds patches to fix some issues in TIPC streaming & service > subscription. Series applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix partial topology connection closure
From: Tuong Lien Date: Mon, 4 May 2020 11:15:54 +0700 > When an application connects to the TIPC topology server and subscribes > to some services, a new connection is created along with some objects - > 'tipc_subscription' to store related data correspondingly... > However, there is one omission in the connection handling that when the > connection or application is orderly shutdown (e.g. via SIGQUIT, etc.), > the connection is not closed in kernel, the 'tipc_subscription' objects > are not freed too. > This results in: > - The maximum number of subscriptions (65535) will be reached soon, new > subscriptions will be rejected; > - TIPC module cannot be removed (unless the objects are somehow forced > to release first); > > The commit fixes the issue by closing the connection if the 'recvmsg()' > returns '0' i.e. when the peer is shutdown gracefully. It also includes > the other unexpected cases. > > Acked-by: Jon Maloy > Acked-by: Ying Xue > Signed-off-by: Tuong Lien Applied, thanks. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix incorrect increasing of link window
From: Tuong Lien
Date: Wed, 15 Apr 2020 18:34:49 +0700
> In commit 16ad3f4022bb ("tipc: introduce variable window congestion
> control"), we allow link window to change with the congestion avoidance
> algorithm. However, there is a bug that during the slow-start if packet
> retransmission occurs, the link will enter the fast-recovery phase, set
> its window to the 'ssthresh' which is never less than 300, so the link
> window suddenly increases to that limit instead of decreasing.
>
> Consequently, two issues have been observed:
>
> - For broadcast-link: it can leave a gap between the link queues that a
> new packet will be inserted and sent before the previous ones, i.e. not
> in-order.
>
> - For unicast: the algorithm does not work as expected, the link window
> jumps to the slow-start threshold whereas packet retransmission occurs.
>
> This commit fixes the issues by avoiding such the link window increase,
> but still decreasing if the 'ssthresh' is lowered.
>
> Fixes: 16ad3f4022bb ("tipc: introduce variable window congestion control")
> Acked-by: Jon Maloy
> Signed-off-by: Tuong Lien
Applied, thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH next] tipc: make three functions static
From: Chen Wandun
Date: Mon, 10 Feb 2020 16:11:09 +0800
> Fix the following sparse warning:
>
> net/tipc/node.c:281:6: warning: symbol 'tipc_node_free' was not declared.
> Should it be static?
> net/tipc/node.c:2801:5: warning: symbol '__tipc_nl_node_set_key' was not
> declared. Should it be static?
> net/tipc/node.c:2878:5: warning: symbol '__tipc_nl_node_flush_key' was not
> declared. Should it be static?
>
> Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
> Fixes: e1f32190cf7d ("tipc: add support for AEAD key setting via netlink")
>
> Signed-off-by: Chen Wandun
Applied.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 1/1] tipc: change maintainer email address
From: Jon Maloy Date: Thu, 23 Jan 2020 10:09:39 -0500 > Reflecting new realities. > > Signed-off-by: Jon Maloy Applied to 'net'. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix wrong connect() return code
From: Tuong Lien Date: Wed, 8 Jan 2020 09:19:00 +0700 > The current 'tipc_wait_for_connect()' function does a wait-loop for the > condition 'sk->sk_state != TIPC_CONNECTING' to conclude if the socket > connecting has done. However, when the condition is met, it returns '0' > even in the case the connecting is actually failed, the socket state is > set to 'TIPC_DISCONNECTING' (e.g. when the server socket has closed..). > This results in a wrong return code for the 'connect()' call from user, > making it believe that the connection is established and go ahead with > building, sending a message, etc. but finally failed e.g. '-EPIPE'. > > This commit fixes the issue by changing the wait condition to the > 'tipc_sk_connected(sk)', so the function will return '0' only when the > connection is really established. Otherwise, either the socket 'sk_err' > if any or '-ETIMEDOUT'/'-EINTR' will be returned correspondingly. > > Acked-by: Ying Xue > Acked-by: Jon Maloy > Signed-off-by: Tuong Lien Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix link overflow issue at socket shutdown
From: Tuong Lien Date: Wed, 8 Jan 2020 09:18:15 +0700 > When a socket is suddenly shutdown or released, it will reject all the > unreceived messages in its receive queue. This applies to a connected > socket too, whereas there is only one 'FIN' message required to be sent > back to its peer in this case. > > In case there are many messages in the queue and/or some connections > with such messages are shutdown at the same time, the link layer will > easily get overflowed at the 'TIPC_SYSTEM_IMPORTANCE' backlog level > because of the message rejections. As a result, the link will be taken > down. Moreover, immediately when the link is re-established, the socket > layer can continue to reject the messages and the same issue happens... > > The commit refactors the '__tipc_shutdown()' function to only send one > 'FIN' in the situation mentioned above. For the connectionless case, it > is unavoidable but usually there is no rejections for such socket > messages because they are 'dest-droppable' by default. > > In addition, the new code makes the other socket states clear > (e.g.'TIPC_LISTEN') and treats as a separate case to avoid misbehaving. > > Acked-by: Ying Xue > Acked-by: Jon Maloy > Signed-off-by: Tuong Lien Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH 2/2] tipc: remove meaningless assignment in Makefile
From: Masahiro Yamada Date: Mon, 6 Jan 2020 16:35:27 +0900 > There is no module named tipc_diag. > > The assignment to tipc_diag-y has no effect. > > Signed-off-by: Masahiro Yamada Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH 1/2] tipc: do not add socket.o to tipc-y twice
From: Masahiro Yamada Date: Mon, 6 Jan 2020 16:35:26 +0900 > net/tipc/Makefile adds socket.o twice. > > tipc-y+= addr.o bcast.o bearer.o \ >core.o link.o discover.o msg.o \ >name_distr.o subscr.o monitor.o name_table.o net.o \ >netlink.o netlink_compat.o node.o socket.o eth_media.o \ > >topsrv.o socket.o group.o trace.o > > > Signed-off-by: Masahiro Yamada Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: make legacy address flag readable over netlink
From: john.rutherf...@dektech.com.au Date: Thu, 19 Dec 2019 16:03:57 +1100 > From: John Rutherford > > To enable iproute2/tipc to generate backwards compatible > printouts and validate command parameters for nodes using a > node address, it needs to be able to read the legacy > address flag from the kernel. The legacy address flag records > the way in which the node identity was originally specified. > > The legacy address flag is requested by the netlink message > TIPC_NL_ADDR_LEGACY_GET. If the flag is set the attribute > TIPC_NLA_NET_ADDR_LEGACY is set in the return message. > > Signed-off-by: John Rutherford > Acked-by: Jon Maloy Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 1/1] tipc: don't send gap blocks in ACK messages
From: Jon Maloy
Date: Mon, 16 Dec 2019 19:21:02 +0100
> In the commit referred to below we eliminated sending of the 'gap'
> indicator in regular ACK messages, reserving this to explicit NACK
> ditto.
>
> Unfortunately we missed to also eliminate building of the 'gap block'
> area in ACK messages. This area is meant to report gaps in the
> received packet sequence following the initial gap, so that lost
> packets can be retransmitted earlier and received out-of-sequence
> packets can be released earlier. However, the interpretation of those
> blocks is dependent on a complete and correct sequence of gaps and
> acks. Hence, when the initial gap indicator is missing a single gap
> block will be interpreted as an acknowledgment of all preceding
> packets. This may lead to packets being released prematurely from the
> sender's transmit queue, with easily predicatble consequences.
>
> We now fix this by not building any gap block area if there is no
> initial gap to report.
>
> Fixes: commit 02288248b051 ("tipc: eliminate gap indicator from ACK messages")
> Signed-off-by: Jon Maloy
Applied, thanks Jon.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net 0/4] tipc: fix some issues
From: Tuong Lien Date: Tue, 10 Dec 2019 15:21:01 +0700 > This series consists of some bug-fixes for TIPC. Series applied, thanks. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 0/3] tipc: introduce variable window congestion control
From: Jon Maloy Date: Tue, 10 Dec 2019 00:52:43 +0100 > We improve thoughput greatly by introducing a variety of the Reno > congestion control algorithm at the link level. Series applied, thanks Jon. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net v1 0/4] Fix some bugs at socket layer
From: Tung Nguyen Date: Thu, 28 Nov 2019 10:10:04 +0700 > This series fixes some bugs at socket layer. Series applied, thanks. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix link name length check
From: john.rutherf...@dektech.com.au
Date: Tue, 26 Nov 2019 13:52:55 +1100
> From: John Rutherford
>
> In commit 4f07b80c9733 ("tipc: check msg->req data len in
> tipc_nl_compat_bearer_disable") the same patch code was copied into
> routines: tipc_nl_compat_bearer_disable(),
> tipc_nl_compat_link_stat_dump() and tipc_nl_compat_link_reset_stats().
> The two link routine occurrences should have been modified to check
> the maximum link name length and not bearer name length.
>
> Fixes: 4f07b80c9733 ("tipc: check msg->reg data len in
> tipc_nl_compat_bearer_disable")
> Signed-off-by: John Rutherford
> Acked-by: Jon Maloy
Applied.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v3] tipc: support in-order name publication events
From: Tuong Lien
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 {1,66,66} scope 2
> Server: bound port A to {1,33,33} scope 2
>
> Now, if a client subscribes to the service range (e.g. {1, 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 {1,33,33}
> Client: received event for published {1,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
> Signed-off-by: Tuong Lien
Applied, thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: update replicast capability for broadcast send link
From: Hoang Le Date: Thu, 21 Nov 2019 10:01:09 +0700 > When setting up a cluster with non-replicast/replicast capability > supported. This capability will be disabled for broadcast send link > in order to be backwards compatible. > > However, when these non-support nodes left and be removed out the cluster. > We don't update this capability on broadcast send link. Then, some of > features that based on this capability will also disabling as unexpected. > > In this commit, we make sure the broadcast send link capabilities will > be re-calculated as soon as a node removed/rejoined a cluster. > > Acked-by: Jon Maloy > Signed-off-by: Hoang Le Applied, thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v2] tipc: support in-order name publication events
From: "Tuong Lien Tong" Date: Thu, 21 Nov 2019 14:01:17 +0700 > Hi David, > > The fact is we still want to keep it with that explicit meaning, so make the > code easy to understand. Yes, the 'time_after32()' or another macro can give > the same result but makes no sense in this particular scenario. Otherwise, > do you like something such as: > > #define publication_after(...) time_after32(...) Yes, that's fine. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v2] tipc: support in-order name publication events
From: Tuong Lien
Date: Thu, 21 Nov 2019 09:53:25 +0700
> +static inline int publication_after(struct publication *pa,
> + struct publication *pb)
> +{
> + return ((int)(pb->id - pa->id) < 0);
> +}
Juse use time32_after() et al. instead of reinventing the same exact
code please.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: support in-order name publication events
From: Tuong Lien Date: Wed, 20 Nov 2019 09:15:19 +0700 > @@ -277,6 +283,17 @@ static struct publication > *tipc_service_remove_publ(struct service_range *sr, > return NULL; > } > > +#define publication_after(pa, pb) (((int)((pb)->id - (pa)->id) < 0)) We have enough of these things, please use existing interfaces such as time32_after() et al. Thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] tipc: add back tipc prefix to log messages
From: Matt Bennett
Date: Thu, 14 Nov 2019 12:20:03 +1300
> The tipc prefix for log messages generated by tipc was
> removed in commit 07f6c4bc048a ("tipc: convert tipc reference
> table to use generic rhashtable").
>
> This is still a useful prefix so add it back.
>
> Signed-off-by: Matt Bennett
Applied.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v2 0/5] TIPC Encryption
From: Tuong Lien Date: Fri, 8 Nov 2019 12:05:07 +0700 > This series provides TIPC encryption feature, kernel part. There will be > another one in the 'iproute2/tipc' for user space to set key. > > v2: add select crypto 'aes(gcm)' for TIPC_CRYPTO in Kconfig Series applied, thanks. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: eliminate checking netns if node established
From: Hoang Le
Date: Fri, 8 Nov 2019 10:02:37 +0700
> Currently, we scan over all network namespaces at each received
> discovery message in order to check if the sending peer might be
> present in a host local namespaces.
>
> This is unnecessary since we can assume that a peer will not change its
> location during an established session.
>
> We now improve the condition for this testing so that we don't perform
> any redundant scans.
>
> Fixes: f73b12812a3d ("tipc: improve throughput between nodes in netns")
> Acked-by: Jon Maloy
> Signed-off-by: Hoang Le
Applied, thank you.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 0/5] TIPC encryption
From: Tuong Lien Date: Fri, 8 Nov 2019 08:42:08 +0700 > This series provides TIPC encryption feature, kernel part. There will be > another one in the 'iproute2/tipc' for user space to set key. If gcm(aes) is the only algorithm you accept, you will need to express this dependency in the Kconfig file. Otherwise it is pointless to turn on the TIPC crypto Kconfig option. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: eliminate the dummy packet in link synching
From: Tuong Lien
Date: Wed, 6 Nov 2019 18:12:17 +0700
> When preparing tunnel packets for the link failover or synchronization,
> as for the safe algorithm, we added a dummy packet on the pair link but
> never sent it out. In the case of failover, the pair link will be reset
> anyway. But for link synching, it will always result in retransmission
> of the dummy packet after that.
> We have also observed that such the retransmission at the early stage
> when a new node comes in a large cluster will take some time and hard
> to be done, leading to the repeated retransmit failures and the link is
> reset.
>
> Since in commit 4929a932be33 ("tipc: optimize link synching mechanism")
> we have already built a dummy 'TUNNEL_PROTOCOL' message on the new link
> for the synchronization, there's no need for the dummy on the pair one,
> this commit will skip it when the new mechanism takes in place. In case
> nothing exists in the pair link's transmq, the link synching will just
> start and stop shortly on the peer side.
>
> The patch is backward compatible.
>
> Acked-by: Jon Maloy
> Tested-by: Hoang Le
> Signed-off-by: Tuong Lien
Applied, thanks Tuong.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 1/2] tipc: update cluster capabilities if node deleted
From: Hoang Le Date: Wed, 6 Nov 2019 13:26:09 +0700 > There are two improvements when re-calculate cluster capabilities: > > - When deleting a specific down node, need to re-calculate. > - In tipc_node_cleanup(), do not need to re-calculate if node > is still existing in cluster. > > Acked-by: Jon Maloy > Signed-off-by: Hoang Le Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 2/2] tipc: reduce sensitive to retransmit failures
From: Hoang Le
Date: Wed, 6 Nov 2019 13:26:10 +0700
> With huge cluster (e.g >200nodes), the amount of that flow:
> gap -> retransmit packet -> acked will take time in case of STATE_MSG
> dropped/delayed because a lot of traffic. This lead to 1.5 sec tolerance
> value criteria made link easy failure around 2nd, 3rd of failed
> retransmission attempts.
>
> Instead of re-introduced criteria of 99 faled retransmissions to fix the
> issue, we increase failure detection timer to ten times tolerance value.
>
> Fixes: 77cf8edbc0e7 ("tipc: simplify stale link failure criteria")
> Acked-by: Jon Maloy
> Signed-off-by: Hoang Le
Applied.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: improve message bundling algorithm
From: Tuong Lien
Date: Fri, 1 Nov 2019 09:58:57 +0700
> As mentioned in commit e95584a889e1 ("tipc: fix unlimited bundling of
> small messages"), the current message bundling algorithm is inefficient
> that can generate bundles of only one payload message, that causes
> unnecessary overheads for both the sender and receiver.
>
> This commit re-designs the 'tipc_msg_make_bundle()' function (now named
> as 'tipc_msg_try_bundle()'), so that when a message comes at the first
> place, we will just check & keep a reference to it if the message is
> suitable for bundling. The message buffer will be put into the link
> backlog queue and processed as normal. Later on, when another one comes
> we will make a bundle with the first message if possible and so on...
> This way, a bundle if really needed will always consist of at least two
> payload messages. Otherwise, we let the first buffer go its way without
> any need of bundling, so reduce the overheads to zero.
>
> Moreover, since now we have both the messages in hand, we can even
> optimize the 'tipc_msg_bundle()' function, make bundle of a very large
> (size ~ MSS) and small messages which is not with the current algorithm
> e.g. [1400-byte message] + [10-byte message] (MTU = 1500).
>
> Acked-by: Ying Xue
> Acked-by: Jon Maloy
> Signed-off-by: Tuong Lien
Applied.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 1/1] tipc: add smart nagle feature
From: Jon Maloy Date: Wed, 30 Oct 2019 14:00:41 +0100 > We introduce a feature that works like a combination of TCP_NAGLE and > TCP_CORK, but without some of the weaknesses of those. In particular, > we will not observe long delivery delays because of delayed acks, since > the algorithm itself decides if and when acks are to be sent from the > receiving peer. > > - The nagle property as such is determined by manipulating a new > 'maxnagle' field in struct tipc_sock. If certain conditions are met, > 'maxnagle' will define max size of the messages which can be bundled. > If it is set to zero no messages are ever bundled, implying that the > nagle property is disabled. > - A socket with the nagle property enabled enters nagle mode when more > than 4 messages have been sent out without receiving any data message > from the peer. > - A socket leaves nagle mode whenever it receives a data message from > the peer. > > In nagle mode, messages smaller than 'maxnagle' are accumulated in the > socket write queue. The last buffer in the queue is marked with a new > 'ack_required' bit, which forces the receiving peer to send a CONN_ACK > message back to the sender upon reception. > > The accumulated contents of the write queue is transmitted when one of > the following events or conditions occur. > > - A CONN_ACK message is received from the peer. > - A data message is received from the peer. > - A SOCK_WAKEUP pseudo message is received from the link level. > - The write queue contains more than 64 1k blocks of data. > - The connection is being shut down. > - There is no CONN_ACK message to expect. I.e., there is currently > no outstanding message where the 'ack_required' bit was set. As a > consequence, the first message added after we enter nagle mode > is always sent directly with this bit set. > > This new feature gives a 50-100% improvement of throughput for small > (i.e., less than MTU size) messages, while it might add up to one RTT > to latency time when the socket is in nagle mode. > > Acked-by: Ying Xue > Signed-off-by: Jon Maloy Applied, thanks Jon. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v2] tipc: improve throughput between nodes in netns
From: Hoang Le
Date: Tue, 29 Oct 2019 07:51:21 +0700
> Currently, TIPC transports intra-node user data messages directly
> socket to socket, hence shortcutting all the lower layers of the
> communication stack. This gives TIPC very good intra node performance,
> both regarding throughput and latency.
>
> We now introduce a similar mechanism for TIPC data traffic across
> network namespaces located in the same kernel. On the send path, the
> call chain is as always accompanied by the sending node's network name
> space pointer. However, once we have reliably established that the
> receiving node is represented by a namespace on the same host, we just
> replace the namespace pointer with the receiving node/namespace's
> ditto, and follow the regular socket receive patch though the receiving
> node. This technique gives us a throughput similar to the node internal
> throughput, several times larger than if we let the traffic go though
> the full network stacks. As a comparison, max throughput for 64k
> messages is four times larger than TCP throughput for the same type of
> traffic.
>
> To meet any security concerns, the following should be noted.
...
> Regarding traceability, we should notice that since commit 6c9081a3915d
> ("tipc: add loopback device tracking") it is possible to follow the node
> internal packet flow by just activating tcpdump on the loopback
> interface. This will be true even for this mechanism; by activating
> tcpdump on the involved nodes' loopback interfaces their inter-name
> space messaging can easily be tracked.
>
> v2:
> - update 'net' pointer when node left/rejoined
> v3:
> - grab read/write lock when using node ref obj
> v4:
> - clone traffics between netns to loopback
>
> Suggested-by: Jon Maloy
> Acked-by: Jon Maloy
> Signed-off-by: Hoang Le
Applied to net-next.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH trivial] tipc: Spelling s/enpoint/endpoint/
From: Geert Uytterhoeven Date: Thu, 24 Oct 2019 17:30:43 +0200 > Fix misspelling of "endpoint". > > Signed-off-by: Geert Uytterhoeven Applied to net-next. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix unlimited bundling of small messages
From: Tuong Lien Date: Wed, 2 Oct 2019 18:49:43 +0700 > We have identified a problem with the "oversubscription" policy in the > link transmission code. ... Applied and queued up for -stable. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: add NULL pointer check before calling kfree_rcu
From: Xin Long
Date: Tue, 3 Sep 2019 17:53:12 +0800
> Unlike kfree(p), kfree_rcu(p, rcu) won't do NULL pointer check. When
> tipc_nametbl_remove_publ returns NULL, the panic below happens:
...
> Fixes: 97ede29e80ee ("tipc: convert name table read-write lock to RCU")
> Reported-by: Li Shuang
> Signed-off-by: Xin Long
Applied and queued up for -stable, thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v2 1/1] tipc: clean up skb list lock handling on send path
From: Jon Maloy
Date: Thu, 15 Aug 2019 16:42:50 +0200
> The policy for handling the skb list locks on the send and receive paths
> is simple.
>
> - On the send path we never need to grab the lock on the 'xmitq' list
> when the destination is an exernal node.
>
> - On the receive path we always need to grab the lock on the 'inputq'
> list, irrespective of source node.
>
> However, when transmitting node local messages those will eventually
> end up on the receive path of a local socket, meaning that the argument
> 'xmitq' in tipc_node_xmit() will become the 'ínputq' argument in the
> function tipc_sk_rcv(). This has been handled by always initializing
> the spinlock of the 'xmitq' list at message creation, just in case it
> may end up on the receive path later, and despite knowing that the lock
> in most cases never will be used.
>
> This approach is inaccurate and confusing, and has also concealed the
> fact that the stated 'no lock grabbing' policy for the send path is
> violated in some cases.
>
> We now clean up this by never initializing the lock at message creation,
> instead doing this at the moment we find that the message actually will
> enter the receive path. At the same time we fix the four locations
> where we incorrectly access the spinlock on the send/error path.
>
> This patch also reverts commit d12cffe9329f ("tipc: ensure head->lock
> is initialised") which has now become redundant.
>
> CC: Eric Dumazet
> Reported-by: Chris Packham
> Acked-by: Ying Xue
> Signed-off-by: Jon Maloy
Applied.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix false detection of retransmit failures
From: Tuong Lien
Date: Thu, 15 Aug 2019 10:24:08 +0700
> This commit eliminates the use of the link 'stale_limit' & 'prev_from'
> (besides the already removed - 'stale_cnt') variables in the detection
> of repeated retransmit failures as there is no proper way to initialize
> them to avoid a false detection, i.e. it is not really a retransmission
> failure but due to a garbage values in the variables.
>
> Instead, a jiffies variable will be added to individual skbs (like the
> way we restrict the skb retransmissions) in order to mark the first skb
> retransmit time. Later on, at the next retransmissions, the timestamp
> will be checked to see if the skb in the link transmq is "too stale",
> that is, the link tolerance time has passed, so that a link reset will
> be ordered. Note, just checking on the first skb in the queue is fine
> enough since it must be the oldest one.
> A counter is also added to keep track the actual skb retransmissions'
> number for later checking when the failure happens.
>
> The downside of this approach is that the skb->cb[] buffer is about to
> be exhausted, however it is always able to allocate another memory area
> and keep a reference to it when needed.
>
> Fixes: 77cf8edbc0e7 ("tipc: simplify stale link failure criteria")
> Reported-by: Hoang Le
> Acked-by: Ying Xue
> Acked-by: Jon Maloy
> Signed-off-by: Tuong Lien
Applied, thank you.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH v2 0/3] Fix three issues found by syzbot
From: Ying Xue Date: Mon, 12 Aug 2019 15:32:39 +0800 > Ying Xue (3): > tipc: fix memory leak issue > tipc: fix memory leak issue Please make the subject lines for these two patches unique. Perhaps mention what part of the tipc code has the memory leak you are fixing. Thanks. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v3] tipc: add loopback device tracking
From: john.rutherf...@dektech.com.au Date: Wed, 7 Aug 2019 12:52:29 +1000 > From: John Rutherford > > Since node internal messages are passed directly to the socket, it is not > possible to observe those messages via tcpdump or wireshark. > > We now remedy this by making it possible to clone such messages and send > the clones to the loopback interface. The clones are dropped at reception > and have no functional role except making the traffic visible. > > The feature is enabled if network taps are active for the loopback device. > pcap filtering restrictions require 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 > Acked-by: Ying Xue Applied, thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 1/1] tipc: reduce risk of wakeup queue starvation
From: Jon Maloy
Date: Tue, 30 Jul 2019 16:23:18 +0200
> In commit 365ad353c256 ("tipc: reduce risk of user starvation during
> link congestion") we allowed senders to add exactly one list of extra
> buffers to the link backlog queues during link congestion (aka
> "oversubscription"). However, the criteria for when to stop adding
> wakeup messages to the input queue when the overload abates is
> inaccurate, and may cause starvation problems during very high load.
>
> Currently, we stop adding wakeup messages after 10 total failed attempts
> where we find that there is no space left in the backlog queue for a
> certain importance level. The counter for this is accumulated across all
> levels, which may lead the algorithm to leave the loop prematurely,
> although there may still be plenty of space available at some levels.
> The result is sometimes that messages near the wakeup queue tail are not
> added to the input queue as they should be.
>
> We now introduce a more exact algorithm, where we keep adding wakeup
> messages to a level as long as the backlog queue has free slots for
> the corresponding level, and stop at the moment there are no more such
> slots or when there are no more wakeup messages to dequeue.
>
> Fixes: 365ad35 ("tipc: reduce risk of user starvation during link congestion")
> Reported-by: Tung Nguyen
> Acked-by: Ying Xue
> Signed-off-by: Jon Maloy
Applied, thank you.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] tipc: compat: allow tipc commands without arguments
From: Taras Kondratiuk
Date: Mon, 29 Jul 2019 22:15:07 +
> Commit 2753ca5d9009 ("tipc: fix uninit-value in tipc_nl_compat_doit")
> broke older tipc tools that use compat interface (e.g. tipc-config from
> tipcutils package):
...
> This patch relaxes the original fix and rejects messages without
> arguments only if such arguments are expected by a command (reg_type is
> non zero).
>
> Fixes: 2753ca5d9009 ("tipc: fix uninit-value in tipc_nl_compat_doit")
> Signed-off-by: Taras Kondratiuk
> ---
> The patch is based on v5.3-rc2.
Applied and queued up for -stable.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] tipc: compat: allow tipc commands without arguments
Jon et al., please review. Thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net 1/1] tipc: fix unitilized skb list crash
From: Jon Maloy Date: Tue, 30 Jul 2019 20:19:10 +0200 > Our test suite somtimes provokes the following crash: > > Description of problem: ... > The reason is that the skb list tipc_socket::mc_method.deferredq only > is initialized for connectionless sockets, while nothing stops arriving > multicast messages from being filtered by connection oriented sockets, > with subsequent access to the said list. > > We fix this by initializing the list unconditionally at socket creation. > This eliminates the crash, while the message still is dropped further > down in tipc_sk_filter_rcv() as it should be. > > Reported-by: Li Shuang > Signed-off-by: Jon Maloy Applied and queued up for -stable, thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] net: tipc: Fix a possible null-pointer dereference in tipc_publ_purge()
From: Jia-Ju Bai Date: Thu, 25 Jul 2019 17:20:21 +0800 > @@ -223,7 +223,8 @@ static void tipc_publ_purge(struct net *net, struct > publication *publ, u32 addr) > publ->key); > } > > - kfree_rcu(p, rcu); > + if (p) > + kfree_rcu(p, rcu); Please fix your automated tools if that is what found this, because as others have nodes kfree_rcu() can take a NULL pointer argument just fine. Thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 0/2] tipc: link changeover issues
From: Tuong Lien Date: Wed, 24 Jul 2019 08:56:10 +0700 > This patch series is to resolve some issues found with the current link > changeover mechanism, it also includes an optimization for the link > synching. Series applied, thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] tipc: Fix a typo
From: Christophe JAILLET Date: Sun, 21 Jul 2019 12:38:11 +0200 > s/tipc_toprsv_listener_data_ready/tipc_topsrv_listener_data_ready/ > (r and s switched in topsrv) > > Signed-off-by: Christophe JAILLET > --- > The function name could also be removed from the comment. It does not > bring any useful information IMHO. Applied, thanks Christophe. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net 1/1] tipc: initialize 'validated' field of received packets
From: Jon Maloy Date: Wed, 17 Jul 2019 23:43:44 +0200 > The tipc_msg_validate() function leaves a boolean flag 'validated' in > the validated buffer's control block, to avoid performing this action > more than once. However, at reception of new packets, the position of > this field may already have been set by lower layer protocols, so > that the packet is erroneously perceived as already validated by TIPC. > > We fix this by initializing the said field to 'false' before performing > the initial validation. > > Signed-off-by: Jon Maloy Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH v2] tipc: ensure head->lock is initialised
From: Chris Packham Date: Fri, 12 Jul 2019 10:41:15 +1200 > tipc_named_node_up() creates a skb list. It passes the list to > tipc_node_xmit() which has some code paths that can call > skb_queue_purge() which relies on the list->lock being initialised. > > The spin_lock is only needed if the messages end up on the receive path > but when the list is created in tipc_named_node_up() we don't > necessarily know if it is going to end up there. > > Once all the skb list users are updated in tipc it will then be possible > to update them to use the unlocked variants of the skb list functions > and initialise the lock when we know the message will follow the receive > path. > > Signed-off-by: Chris Packham Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 0/2] tipc: link changeover issues
net-next is closed right now, resubmit this when the tree opens back up. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] tipc: use rcu dereference functions properly
From: David Miller Date: Sat, 06 Jul 2019 15:15:44 -0700 (PDT) > From: Xin Long > Date: Sat, 6 Jul 2019 14:48:48 +0800 > >> Hi, David, I saw this patch in "Changes Requested". > > I just put it back to Under Review, thanks. Applied to net-next, thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] tipc: use rcu dereference functions properly
From: Xin Long Date: Sat, 6 Jul 2019 14:48:48 +0800 > Hi, David, I saw this patch in "Changes Requested". I just put it back to Under Review, thanks. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net-next] tipc: remove ub->ubsock checks
From: Xin Long Date: Tue, 2 Jul 2019 00:57:19 +0800 > Both tipc_udp_enable and tipc_udp_disable are called under rtnl_lock, > ub->ubsock could never be NULL in tipc_udp_disable and cleanup_bearer, > so remove the check. > > Also remove the one in tipc_udp_enable by adding "free" label. > > Signed-off-by: Xin Long Looks good, applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 1/1] tipc: embed jiffies in macro TIPC_BC_RETR_LIM
From: Jon Maloy Date: Fri, 28 Jun 2019 17:06:20 +0200 > The macro TIPC_BC_RETR_LIM is always used in combination with 'jiffies', > so we can just as well perform the addition in the macro itself. This > way, we get a few shorter code lines and one less line break. > > Signed-off-by: Jon Maloy Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: add dst_cache support for udp media
From: Xin Long Date: Thu, 20 Jun 2019 19:03:41 +0800 > As other udp/ip tunnels do, tipc udp media should also have a > lockless dst_cache supported on its tx path. > > Here we add dst_cache into udp_replicast to support dst cache > for both rmcast and rcast, and rmcast uses ub->rcast and each > rcast uses its own node in ub->rcast.list. > > Signed-off-by: Xin Long Applied to net-next. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 1/1] tipc: rename function msg_get_wrapped() to msg_inner_hdr()
From: Jon Maloy Date: Tue, 25 Jun 2019 19:37:00 +0200 > We rename the inline function msg_get_wrapped() to the more > comprehensible msg_inner_hdr(). > > Signed-off-by: Jon Maloy Applied, thanks Jon. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 1/1] tipc: eliminate unnecessary skb expansion during retransmission
From: Jon Maloy Date: Tue, 25 Jun 2019 18:08:13 +0200 > We increase the allocated headroom for the buffer copies to be > retransmitted. This eliminates the need for the lower stack levels > (UDP/IP/L2) to expand the headroom in order to add their own headers. > > Signed-off-by: Jon Maloy Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next 1/1] tipc: simplify stale link failure criteria
From: Jon Maloy
Date: Tue, 25 Jun 2019 17:36:43 +0200
> In commit a4dc70d46cf1 ("tipc: extend link reset criteria for stale
> packet retransmission") we made link retransmission failure events
> dependent on the link tolerance, and not only of the number of failed
> retransmission attempts, as we did earlier. This works well. However,
> keeping the original, additional criteria of 99 failed retransmissions
> is now redundant, and may in some cases lead to failure detection
> times in the order of minutes instead of the expected 1.5 sec link
> tolerance value.
>
> We now remove this criteria altogether.
>
> Acked-by: Ying Xue
> Signed-off-by: Jon Maloy
Applied.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCHv2 net] tipc: check msg->req data len in tipc_nl_compat_bearer_disable
From: Xin Long
Date: Tue, 25 Jun 2019 00:28:19 +0800
> This patch is to fix an uninit-value issue, reported by syzbot:
...
> TLV_GET_DATA_LEN() may return a negtive int value, which will be
> used as size_t (becoming a big unsigned long) passed into memchr,
> cause this issue.
>
> Similar to what it does in tipc_nl_compat_bearer_enable(), this
> fix is to return -EINVAL when TLV_GET_DATA_LEN() is negtive in
> tipc_nl_compat_bearer_disable(), as well as in
> tipc_nl_compat_link_stat_dump() and tipc_nl_compat_link_reset_stats().
>
> v1->v2:
> - add the missing Fixes tags per Eric's request.
>
> Fixes: 0762216c0ad2 ("tipc: fix uninit-value in tipc_nl_compat_bearer_enable")
> Fixes: 8b66fee7f8ee ("tipc: fix uninit-value in
> tipc_nl_compat_link_reset_stats")
> Reported-by: syzbot+30eaa8bf392f7faff...@syzkaller.appspotmail.com
> Signed-off-by: Xin Long
Applied and queued up for -stable, thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: check msg->req data len in tipc_nl_compat_bearer_disable
From: Xin Long Date: Tue, 25 Jun 2019 00:00:39 +0800 > Sorry, David, do I need to resend this one? Yes, please, that helps me a lot. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: remove the unnecessary msg->req check from tipc_nl_compat_bearer_set
From: Xin Long Date: Mon, 24 Jun 2019 23:54:02 +0800 > On Mon, Jun 24, 2019 at 10:35 PM David Miller wrote: >> >> From: Xin Long >> Date: Mon, 24 Jun 2019 16:02:42 +0800 >> >> > tipc_nl_compat_bearer_set() is only called by tipc_nl_compat_link_set() >> > which already does the check for msg->req check, so remove it from >> > tipc_nl_compat_bearer_set(), and do the same in tipc_nl_compat_media_set(). >> > >> > Signed-off-by: Xin Long >> >> Is this really appropriate as a fix for 'net'? Seems more like net-next >> material >> to me. > kind of code fix, sure, you can apply it to net-next, no conflict. > do you need me to repost? No need to resend, applied to net-next, thanks! ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: fix missing indentation in source code
From: John Rutherford
Date: Mon, 24 Jun 2019 14:01:23 +1000
> Fix misalignment of policy statement in netlink.c due to automatic
> spatch code transformation.
>
> Fixes: 3b0f31f2b8c9 ("genetlink: make policy common to family")
> Acked-by: Jon Maloy
> Signed-off-by: John Rutherford
Applied.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: change to use register_pernet_device
From: Xin Long Date: Thu, 20 Jun 2019 18:39:28 +0800 > This patch is to fix a dst defcnt leak, which can be reproduced by doing: > > # ip net a c; ip net a s; modprobe tipc > # ip net e s ip l a n eth1 type veth peer n eth1 netns c > # ip net e c ip l s lo up; ip net e c ip l s eth1 up > # ip net e s ip l s lo up; ip net e s ip l s eth1 up > # ip net e c ip a a 1.1.1.2/8 dev eth1 > # ip net e s ip a a 1.1.1.1/8 dev eth1 > # ip net e c tipc b e m udp n u1 localip 1.1.1.2 > # ip net e s tipc b e m udp n u1 localip 1.1.1.1 > # ip net d c; ip net d s; rmmod tipc > > and it will get stuck and keep logging the error: > > unregister_netdevice: waiting for lo to become free. Usage count = 1 > > The cause is that a dst is held by the udp sock's sk_rx_dst set on udp rx > path with udp_early_demux == 1, and this dst (eventually holding lo dev) > can't be released as bearer's removal in tipc pernet .exit happens after > lo dev's removal, default_device pernet .exit. > > "There are two distinct types of pernet_operations recognized: subsys and > device. At creation all subsys init functions are called before device > init functions, and at destruction all device exit functions are called > before subsys exit function." > > So by calling register_pernet_device instead to register tipc_net_ops, the > pernet .exit() will be invoked earlier than loopback dev's removal when a > netns is being destroyed, as fou/gue does. > > Note that vxlan and geneve udp tunnels don't have this issue, as the udp > sock is released in their device ndo_stop(). > > This fix is also necessary for tipc dst_cache, which will hold dsts on tx > path and I will introduce in my next patch. > > Reported-by: Li Shuang > Signed-off-by: Xin Long Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net] tipc: fix issues with early FAILOVER_MSG from peer
From: Tuong Lien Date: Mon, 17 Jun 2019 11:56:12 +0700 > It appears that a FAILOVER_MSG can come from peer even when the failure > link is resetting (i.e. just after the 'node_write_unlock()'...). This > means the failover procedure on the node has not been started yet. > The situation is as follows: ... > Once this happens, the link failover procedure will be triggered > wrongly on the receiving node since the node isn't in FAILINGOVER state > but then another link failover will be carried out. > The consequences are: > > 1) A peer might get stuck in FAILINGOVER state because the 'sync_point' > was set, reset and set incorrectly, the criteria to end the failover > would not be met, it could keep waiting for a message that has already > received. > > 2) The early FAILOVER_MSG(s) could be queued in the link failover > deferdq but would be purged or not pulled out because the 'drop_point' > was not set correctly. > > 3) The early FAILOVER_MSG(s) could be dropped too. > > 4) The dummy FAILOVER_MSG could make the peer leaving FAILINGOVER state > shortly, but later on it would be restarted. > > The same situation can also happen when the link is in PEER_RESET state > and a FAILOVER_MSG arrives. > > The commit resolves the issues by forcing the link down immediately, so > the failover procedure will be started normally (which is the same as > when receiving a FAILOVER_MSG and the link is in up state). > > Also, the function "tipc_node_link_failover()" is toughen to avoid such > a situation from happening. > > Acked-by: Jon Maloy > Signed-off-by: Tuong Lien Applied, thank you. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: include retrans failure detection for unicast
From: Tuong Lien
Date: Mon, 17 Jun 2019 12:15:42 +0700
> In patch series, commit 9195948fbf34 ("tipc: improve TIPC throughput by
> Gap ACK blocks"), as for simplicity, the repeated retransmit failures'
> detection in the function - "tipc_link_retrans()" was kept there for
> broadcast retransmissions only.
>
> This commit now reapplies this feature for link unicast retransmissions
> that has been done via the function - "tipc_link_advance_transmq()".
>
> Also, the "tipc_link_retrans()" is renamed to "tipc_link_bc_retrans()"
> as it is used only for broadcast.
>
> Acked-by: Jon Maloy
> Signed-off-by: Tuong Lien
Applied, thank you.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net] tipc: purge deferredq list for each grp member in tipc_group_delete
From: Xin Long
Date: Sun, 16 Jun 2019 17:24:07 +0800
> Syzbot reported a memleak caused by grp members' deferredq list not
> purged when the grp is be deleted.
>
> The issue occurs when more(msg_grp_bc_seqno(hdr), m->bc_rcv_nxt) in
> tipc_group_filter_msg() and the skb will stay in deferredq.
>
> So fix it by calling __skb_queue_purge for each member's deferredq
> in tipc_group_delete() when a tipc sk leaves the grp.
>
> Fixes: b87a5ea31c93 ("tipc: guarantee group unicast doesn't bypass group
> broadcast")
> Reported-by: syzbot+78fbe679c8ca8d264...@syzkaller.appspotmail.com
> Signed-off-by: Xin Long
Applied, thanks.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH net v1] tipc: fix hanging clients using poll with EPOLLOUT flag
From: Parthasarathy Bhuvaragan
Date: Thu, 9 May 2019 07:13:42 +0200
> commit 517d7c79bdb398 ("tipc: fix hanging poll() for stream sockets")
> introduced a regression for clients using non-blocking sockets.
> After the commit, we send EPOLLOUT event to the client even in
> TIPC_CONNECTING state. This causes the subsequent send() to fail
> with ENOTCONN, as the socket is still not in TIPC_ESTABLISHED state.
>
> In this commit, we:
> - improve the fix for hanging poll() by replacing sk_data_ready()
> with sk_state_change() to wake up all clients.
> - revert the faulty updates introduced by commit 517d7c79bdb398
> ("tipc: fix hanging poll() for stream sockets").
>
> Fixes: 517d7c79bdb398 ("tipc: fix hanging poll() for stream sockets")
> Signed-off-by: Parthasarathy Bhuvaragan
> Acked-by: Jon Maloy
Applied and queued up for -stable.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next] tipc: fix missing Name entries due to half-failover
From: Tuong Lien
Date: Thu, 2 May 2019 17:23:23 +0700
> TIPC link can temporarily fall into "half-establish" that only one of
> the link endpoints is ESTABLISHED and starts to send traffic, PROTOCOL
> messages, whereas the other link endpoint is not up (e.g. immediately
> when the endpoint receives ACTIVATE_MSG, the network interface goes
> down...).
>
> This is a normal situation and will be settled because the link
> endpoint will be eventually brought down after the link tolerance time.
>
> However, the situation will become worse when the second link is
> established before the first link endpoint goes down,
> For example:
>
>1. Both links <1A-2A>, <1B-2B> down
>2. Link endpoint 2A up, but 1A still down (e.g. due to network
> disturbance, wrong session, etc.)
>3. Link <1B-2B> up
>4. Link endpoint 2A down (e.g. due to link tolerance timeout)
>5. Node B starts failover onto link <1B-2B>
>
>==> Node A does never start link failover.
>
> When the "half-failover" situation happens, two consequences have been
> observed:
>
> a) Peer link/node gets stuck in FAILINGOVER state;
> b) Traffic or user messages that peer node is trying to failover onto
> the second link can be partially or completely dropped by this node.
>
> The consequence a) was actually solved by commit c140eb166d68 ("tipc:
> fix failover problem"), but that commit didn't cover the b). It's due
> to the fact that the tunnel link endpoint has never been prepared for a
> failover, so the 'l->drop_point' (and the other data...) is not set
> correctly. When a TUNNEL_MSG from peer node arrives on the link,
> depending on the inner message's seqno and the current 'l->drop_point'
> value, the message can be dropped (- treated as a duplicate message) or
> processed.
> At this early stage, the traffic messages from peer are likely to be
> NAME_DISTRIBUTORs, this means some name table entries will be missed on
> the node forever!
>
> The commit resolves the issue by starting the FAILOVER process on this
> node as well. Another benefit from this solution is that we ensure the
> link will not be re-established until the failover ends.
>
> Acked-by: Jon Maloy
> Signed-off-by: Tuong Lien
Applied, thank you.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [PATCH] tipc: Avoid copying bytes beyond the supplied data
From: Chris Packham Date: Thu, 2 May 2019 15:10:04 +1200 > TLV_SET is called with a data pointer and a len parameter that tells us > how many bytes are pointed to by data. When invoking memcpy() we need > to careful to only copy len bytes. > > Previously we would copy TLV_LENGTH(len) bytes which would copy an extra > 4 bytes past the end of the data pointer which newer GCC versions > complain about. > > In file included from test.c:17: > In function 'TLV_SET', > inlined from 'test' at test.c:186:5: > /usr/include/linux/tipc_config.h:317:3: > warning: 'memcpy' forming offset [33, 36] is out of the bounds [0, 32] > of object 'bearer_name' with type 'char[32]' [-Warray-bounds] > memcpy(TLV_DATA(tlv_ptr), data, tlv_len); > ^~~~ > test.c: In function 'test': > test.c::161:10: note: > 'bearer_name' declared here > char bearer_name[TIPC_MAX_BEARER_NAME]; > ^~~ > > Signed-off-by: Chris Packham But now the pad bytes at the end are uninitialized. The whole idea is that the encapsulating TLV object has to be rounded up in size based upon the given 'len' for the data. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] [net-next v1] tipc: introduce new socket option TIPC_SOCK_RECVQ_USED
From: Jon Maloy Date: Fri, 19 Apr 2019 21:51:31 + > > >> -Original Message- >> From: netdev-ow...@vger.kernel.org >> On Behalf Of David Miller >> Sent: 19-Apr-19 17:41 >> To: Tung Quang Nguyen >> Cc: net...@vger.kernel.org; tipc-discussion@lists.sourceforge.net >> Subject: Re: [tipc-discussion][net-next v1] tipc: introduce new socket option >> TIPC_SOCK_RECVQ_USED >> >> From: Tung Nguyen >> Date: Thu, 18 Apr 2019 21:02:19 +0700 >> >> > When using TIPC_SOCK_RECVQ_DEPTH for getsockopt(), it returns the >> > number of buffers in receive socket buffer which is not so helpful for >> > user space applications. >> > >> > This commit introduces the new option TIPC_SOCK_RECVQ_USED which >> > returns the current allocated bytes of the receive socket buffer. >> > This helps user space applications dimension its buffer usage to avoid >> > buffer overload issue. >> > >> > Signed-off-by: Tung Nguyen >> >> TIPC folks, please review. > > Acked-by: Jon Maloy Applied, thanks for reviewing. > It would of course be nicer if we could recycle > TIPC_SOCK_RECV_QUEUE_DEPTH for this purpose, but that would mean > altering the current ABI and incur a (probably very low) risk of > breaking existing application. I am not particularly happy with > this, but do we have users who claim it would be useful for them. Better safe than sorry when it comes to user facing ABIs. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
