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.
___
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`
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):
>
>
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
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
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.
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
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[])
>
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?
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
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
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
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
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
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
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
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
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 &&
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
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
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,
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
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/)
>
>
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
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.
>
>
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
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
net-next is CLOSED, thank you
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
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
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:
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:
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
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
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
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
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
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
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
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
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
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
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
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: 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
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
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
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
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(),
>
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:
>
>
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
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
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
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,
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
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.
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
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
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
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.
>
>
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
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
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
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
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
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
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
>
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
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
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.
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
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,
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
Jon et al., please review.
Thank you.
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
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
>
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
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.
___
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
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
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
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
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.
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
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.
>
>
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
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
>
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
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
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
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
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
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()
>&
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.
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
>
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
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
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.
>
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.
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
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
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-discu
1 - 100 of 314 matches
Mail list logo
