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 >

Re: [tipc-discussion] [PATCH net] tipc: set sysctl_tipc_rmem and named_timeout right range

From: Zhiqiang Liu Date: Tue, 16 Apr 2019 13:10:09 +0800 > From: Jie Liu > > We find that sysctl_tipc_rmem and named_timeout do not have the right minimum > setting. sysctl_tipc_rmem should be larger than zero, like sysctl_tcp_rmem. > And named_timeout as a timeout setting should be not less

Re: [tipc-discussion] [net] tipc: fix link established but not in session

From: Tuong Lien Date: Tue, 16 Apr 2019 10:48:07 +0700 > According to the link FSM, when a link endpoint got RESET_MSG (- a > traditional one without the stopping bit) from its peer, it moves to > PEER_RESET state and raises a LINK_DOWN event which then resets the > link itself. Its state will

Re: [tipc-discussion] [net-next v2 1/1] tipc: use standard write_lock & unlock functions when creating node

From: Jon Maloy Date: Thu, 11 Apr 2019 21:56:28 +0200 > In the function tipc_node_create() we protect the peer capability field > by using the node rw_lock. However, we access the lock directly instead > of using the dedicated functions for this, as we do everywhere else in > node.c. This

Re: [tipc-discussion] [net-next 1/1] tipc: use standard write_lock & unlock functions when creating node

From: Jon Maloy Date: Thu, 11 Apr 2019 20:27:08 +0200 > In the function tipc_node_create() we protect the peer capability field > by using the node rw_lock. However, we access the lock directly instead > of using the dedicated functions for this, as we do everywhere else in > node.c. This

Re: [tipc-discussion] [net-next 0/3] tipc: improve TIPC unicast link throughput

From: Tuong Lien Date: Thu, 4 Apr 2019 11:09:50 +0700 > The series introduces an algorithm to improve TIPC throughput especially > in terms of packet loss, also tries to reduce packet duplication due to > overactive NACK sending mechanism. > > The link failover situation is also covered by the

Re: [tipc-discussion] [net-next] tipc: add NULL pointer check

From: Hoang Le Date: Wed, 3 Apr 2019 13:05:04 +0700 > skb somehow dequeued out of inputq before processing, it causes to > NULL pointer and kernel crashed. > > Add checking skb valid before using. > > Fixes: c55c8edafa9 ("tipc: smooth change between replicast and broadcast") > Reported-by:

Re: [tipc-discussion] [PATCH net 0/3] tipc: a batch of uninit-value fixes for netlink_compat

From: Jon Maloy Date: Sun, 31 Mar 2019 22:27:19 + > All three acked by me. Series applied. Jon, please provide a formal, full: Acked-by: David S. Miller next time. Thank you. ___ tipc-discussion mailing list

Re: [tipc-discussion] [PATCH net-next v2] tipc: fix return value check in tipc_mcast_send_sync()

From: Wei Yongjun Date: Mon, 25 Mar 2019 06:31:09 + > Fix the return value check which testing the wrong variable > in tipc_mcast_send_sync(). > > Fixes: c55c8edafa91 ("tipc: smooth change between replicast and broadcast") > Reported-by: Hulk Robot > Signed-off-by: Wei Yongjun > --- > v1

Re: [tipc-discussion] [PATCH net] tipc: change to check tipc_own_id to return in tipc_net_stop

From: Xin Long Date: Sun, 24 Mar 2019 00:48:22 +0800 > When running a syz script, a panic occurred: ... > It was caused by the netns freed without deleting the discoverer timer, > while later on the netns would be accessed in the timer handler. > > The timer should have been deleted by

Re: [tipc-discussion] [net 1/1] tipc: tipc clang warning

From: Jon Maloy Date: Fri, 22 Mar 2019 15:03:51 +0100 > When checking the code with clang -Wsometimes-uninitialized we get the > following warning: > > if (!tipc_link_is_establishing(l)) { > ^ > net/tipc/node.c:847:46: note: uninitialized use occurs here >

Re: [tipc-discussion] [net-next v1 2/2] tipc: fix a null pointer deref

From: Hoang Le Date: Thu, 21 Mar 2019 17:25:18 +0700 > In commit c55c8edafa91 ("tipc: smooth change between replicast and > broadcast") we introduced new method to eliminate the risk of message > reordering that happen in between different nodes. > Unfortunately, we forgot checking at receiving

Re: [tipc-discussion] [net-next v1 1/2] tipc: fix use-after-free in tipc_sk_filter_rcv

From: Hoang Le Date: Thu, 21 Mar 2019 17:25:17 +0700 > skb free-ed in: > 1/ condition 1: tipc_sk_filter_rcv -> tipc_sk_proto_rcv > 2/ condition 2: tipc_sk_filter_rcv -> tipc_group_filter_msg > This leads to a "use-after-free" access in the next condition. > > We fix this by intializing the

Re: [tipc-discussion] [net v2 1/1] tipc: fix cancellation of topology subscriptions

From: Jon Maloy Date: Thu, 21 Mar 2019 09:11:59 +0100 > From: Erik Hugne > > When cancelling a subscription, we have to clear the cancel bit in the > request before iterating over any established subscriptions with memcmp. > Otherwise no subscription will ever be found, and it will not be >

Re: [tipc-discussion] [net 1/1] tipc: fix cancellation of topology subscriptions

From: Jon Maloy Date: Wed, 20 Mar 2019 10:59:03 +0100 > From: Erik Hugne > > When cancelling a subscription, we have to clear the cancel bit in the > request before iterating over any established subscriptions with memcmp. > Otherwise no subscription will ever be found, and it will not be >

Re: [tipc-discussion] [net-next v3 1/3] tipc: support broadcast/replicast configurable for bc-link

From: Hoang Le Date: Tue, 19 Mar 2019 18:49:48 +0700 > Currently, a multicast stream uses either broadcast or replicast as > transmission method, based on the ratio between number of actual > destinations nodes and cluster size. > > However, when an L2 interface (e.g., VXLAN) provides pseudo >

Re: [tipc-discussion] [net-next v3 3/3] tipc: smooth change between replicast and broadcast

From: Hoang Le Date: Tue, 19 Mar 2019 18:49:50 +0700 > Currently, a multicast stream may start out using replicast, because > there are few destinations, and then it should ideally switch to > L2/broadcast IGMP/multicast when the number of destinations grows beyond > a certain limit. The

Re: [tipc-discussion] [PATCH] net: tipc: fix a missing check for nla_nest_start

From: Kangjie Lu Date: Sat, 16 Mar 2019 16:46:05 -0500 > nla_nest_start may fail. The fix check its status and returns > -EMSGSIZE in case it fails. > > Signed-off-by: Kangjie Lu Applied, thanks. ___ tipc-discussion mailing list

Re: [tipc-discussion] [net 1/1] tipc: allow service ranges to be connect()'ed on RDM/DGRAM

From: Jon Maloy Date: Fri, 15 Mar 2019 21:11:00 +0100 > @@ -2349,6 +2349,16 @@ static int tipc_wait_for_connect(struct socket *sock, > long *timeo_p) > return 0; > } > > +static int tipc_sockaddr_is_sane(struct sockaddr_tipc *addr) > +{ > + if (addr->family != AF_TIPC) > +

Re: [tipc-discussion] [PATCH] net: tipc: fix a missing check of nla_nest_start

From: Kangjie Lu Date: Fri, 15 Mar 2019 12:11:59 -0500 > nla_nest_start could fail and requires a check. The fix returns > -EMSGSIZE if it fails. > > Signed-off-by: Kangjie Lu Applied. ___ tipc-discussion mailing list

Re: [tipc-discussion] [PATCH] net: socket: fix a missing check for nla_nest_start

From: Kangjie Lu Date: Fri, 15 Mar 2019 01:03:05 -0500 > nla_nest_start may fail. The fix check its status and returns > -EMSGSIZE in case it fails. > > Signed-off-by: Kangjie Lu The proper subsystem prefix is "tipc: " not "socket: " ___

Re: [tipc-discussion] [net 1/1] tipc: fix RDM/DGRAM connect() regression

From: Jon Maloy Date: Mon, 4 Mar 2019 23:26:10 +0100 > From: Erik Hugne > > Fix regression bug introduced in > commit 365ad353c256 ("tipc: reduce risk of user starvation during link > congestion") > > Only signal -EDESTADDRREQ for RDM/DGRAM if we don't have a cached > sockaddr. > >

Re: [tipc-discussion] [net v3 1/1] tipc: fix race condition causing hung sendto

From: Tung Nguyen Date: Mon, 25 Feb 2019 10:57:20 +0700 > When sending multicast messages via blocking socket, > if sending link is congested (tsk->cong_link_cnt is set to 1), > the sending thread will be put into sleeping state. However, > tipc_sk_filter_rcv() is called under socket spin lock

Re: [tipc-discussion] [net v2 1/1] tipc: fix race condition causing hung sendto

From: Tung Nguyen Date: Thu, 21 Feb 2019 10:31:21 +0700 > When sending multicast messages via blocking socket, This patch does not apply cleanly to net, please respin: [davem@localhost net]$ git am --signoff tipc-discussion-net-v2-1-1-tipc-fix-race-condition-causing-hung-sendto.patch

Re: [tipc-discussion] [net-next 3/3] tipc: smooth change between replicast and broadcast

From: Hoang Le Date: Tue, 19 Feb 2019 18:30:54 +0700 > +static int tipc_mcast_send_sync(struct net *net, struct sk_buff *skb, > + struct tipc_mc_method *method, > + struct tipc_nlist *dests, > + u16

Re: [tipc-discussion] [net 0/2] improvement for wait and wakeup

From: Tung Nguyen Date: Tue, 19 Feb 2019 11:20:46 +0700 > Some improvements for tipc_wait_for_xzy(). Series applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Re: [tipc-discussion] [net v2 1/1] tipc: fix race condition causing hung sendto

So if the previous version didn't even compile, I have to ask. How did you test this? ___ 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 race condition causing hung sendto

From: Tung Nguyen Date: Tue, 19 Feb 2019 14:03:10 +0700 > When sending multicast messages via blocking socket, > if sending link is congested (tsk->cong_link_cnt is set to 1), > the sending thread will be put into sleeping state. However, > tipc_sk_filter_rcv() is called under socket spin lock

Re: [tipc-discussion] [net] tipc: fix link session and re-establish issues

From: Tuong Lien Date: Mon, 11 Feb 2019 13:29:43 +0700 > When a link endpoint is re-created (e.g. after a node reboot or > interface reset), the link session number is varied by random, the peer > endpoint will be synced with this new session number before the link is > re-established. > >

Re: [tipc-discussion] [net] tipc: fix skb may be leaky in tipc_link_input

From: Hoang Le Date: Mon, 11 Feb 2019 09:18:28 +0700 > When we free skb at tipc_data_input, we return a 'false' boolean. > Then, skb passed to subcalling tipc_link_input in tipc_link_rcv, > > > 1303 int tipc_link_rcv: > ... > 1354if (!tipc_data_input(l, skb, l->inputq)) > 1355rc |=

Re: [tipc-discussion] [PATCH] tipc: remove dead code in struct tipc_topsrv

From: Zhaolong Zhang Date: Thu, 24 Jan 2019 10:06:41 +0800 > max_rcvbuf_size is no longer used since commit "414574a0af36". > > Signed-off-by: Zhaolong Zhang Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net

Re: [tipc-discussion] [PATCH net-next] tipc: mark expected switch fall-throughs

From: "Gustavo A. R. Silva" Date: Wed, 23 Jan 2019 01:09:31 -0600 > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > This patch fixes the following warnings: > > net/tipc/link.c:1125:6: warning: this statement may fall through

Re: [tipc-discussion] [PATCH net-next] tipc: remove unneeded semicolon in trace.c

From: YueHaibing Date: Thu, 17 Jan 2019 20:57:08 +0800 > Remove unneeded semicolon > > Signed-off-by: YueHaibing Applied. ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net

Re: [tipc-discussion] [PATCH] tipc: fix memory leak in tipc_nl_compat_publ_dump

From: "Gustavo A. R. Silva" Date: Sat, 5 Jan 2019 10:52:23 -0600 > There is a memory leak in case genlmsg_put fails. > > Fix this by freeing *args* before return. > > Addresses-Coverity-ID: 1476406 ("Resource leak") > Fixes: 46273cf7e009 ("tipc: fix a missing check of genlmsg_put") >

Re: [tipc-discussion] [PATCH net] tipc: fix uninit-value in tipc_nl_compat_link_set

From: Ying Xue Date: Mon, 7 Jan 2019 19:29:52 +0800 > This is because lc->name string is not validated before it's used. It looks like we have several situations like this, not just this one. For example, tipc_nl_compat_bearer_{enable,disable}() with b->name. Next, tipc_nl_compat_media_set()

Re: [tipc-discussion] [PATCH] tipc: fix a missing check of genlmsg_put

From: Kangjie Lu Date: Wed, 26 Dec 2018 00:09:04 -0600 > genlmsg_put could fail. The fix inserts a check of its return value, and > if it fails, returns -EMSGSIZE. > > Signed-off-by: Kangjie Lu Applied. ___ tipc-discussion mailing list

Re: [tipc-discussion] [PATCH] net/netlink_compat: Fix a missing check of nla_parse_nested

From: Aditya Pakki Date: Sun, 23 Dec 2018 18:54:53 -0600 > In tipc_nl_compat_sk_dump(), if nla_parse_nested() fails, it could return > an error. To be consistent with other invocations of the function call, > on error, the fix passes the return value upstream. > > Signed-off-by: Aditya Pakki

Re: [tipc-discussion] [net] tipc: fix uninitialized value for broadcast retransmission

From: Hoang Le Date: Wed, 19 Dec 2018 09:52:52 +0700 > When sending broadcast message on high load system, there are a lot of > unnecessary packets restranmission. That issue was caused by missing in > initial criteria for retransmission. > > To prevent this happen, just initialize this

Re: [tipc-discussion] [net-next 0/5] tipc: tracepoints and trace_events in TIPC

From: Tuong Lien Date: Wed, 19 Dec 2018 09:17:55 +0700 > The patch series is the first step of introducing a tracing framework in > TIPC, which will assist in collecting complete & plentiful data for post > analysis, even in the case of a single failure occurrence e.g. when the > failure is

Re: [tipc-discussion] [PATCH net-next] tipc: handle broadcast NAME_DISTRIBUTOR packet when receiving it

From: Zhenbo Gao Date: Tue, 18 Dec 2018 17:43:52 +0800 > NAME_DISTRIBUTOR messages are transmitted through unicast link on TIPC > 2.0, by contrast, the messages are delivered through broadcast link on > TIPC 1.7. But at present, NAME_DISTRIBUTOR messages received by > broadcast link cannot be

Re: [tipc-discussion] [net-next] tipc: fix node keep alive interval calculation

From: Hoang Le Date: Thu, 6 Dec 2018 09:00:09 +0700 > When setting LINK tolerance, node timer interval will be calculated > base on the LINK with lowest tolerance. > > But when calculated, the old node timer interval only updated if current > setting value (tolerance/4) less than old ones

Re: [tipc-discussion] [net 1/1] tipc: eliminate message disordering during binding table update

From: Jon Maloy Date: Fri, 19 Oct 2018 19:55:40 +0200 > We have seen the following race scenario: > 1) named_distribute() builds a "bulk" message, containing a PUBLISH >item for a certain publication. This is based on the contents of >the binding tables's 'cluster_scope' list. > 2)

Re: [tipc-discussion] [PATCH] tipc: use destination length for copy string

From: Guoqing Jiang Date: Fri, 19 Oct 2018 12:08:22 +0800 > Got below warning with gcc 8.2 compiler. > > net/tipc/topsrv.c: In function ‘tipc_topsrv_start’: > net/tipc/topsrv.c:660:2: warning: ‘strncpy’ specified bound depends on the > length of the source argument [-Wstringop-overflow=] >

Re: [tipc-discussion] [net 1/1] tipc: fix info leak from kernel tipc_event

From: Jon Maloy Date: Thu, 18 Oct 2018 17:38:29 +0200 > We initialize a struct tipc_event allocated on the kernel stack to > zero to avert info leak to user space. > > Reported-by: syzbot+057458894bc8cada4...@syzkaller.appspotmail.com > Signed-off-by: Jon Maloy Applied and queued up for

Re: [tipc-discussion] [net 1/1] tipc: fix unsafe rcu locking when accessing publication list

From: Jon Maloy Date: Fri, 12 Oct 2018 22:46:55 +0200 > From: Tung Nguyen > > The binding table's 'cluster_scope' list is rcu protected to handle > races between threads changing the list and those traversing the list at > the same moment. We have now found that the function named_distribute()

Re: [tipc-discussion] [net-next] tipc: support binding to specific ip address when activating UDP bearer

From: Hoang Le Date: Thu, 11 Oct 2018 08:43:08 +0700 > INADDR_ANY is hard-coded when activating UDP bearer. So, we could not > bind to a specific IP address even with replicast mode using - given > remote ip address instead of using multicast ip address. > > In this commit, we fixed it by

Re: [tipc-discussion] [PATCH net] tipc: eliminate possible recursive locking detected by LOCKDEP

From: Ying Xue Date: Thu, 11 Oct 2018 19:57:56 +0800 > When booting kernel with LOCKDEP option, below warning info was found: > > WARNING: possible recursive locking detected > 4.19.0-rc7+ #14 Not tainted ... > The reason why the noise above was complained by LOCKDEP is because we > nested to

Re: [tipc-discussion] [net 1/1] tipc: queue socket protocol error messages into socket receive buffer

From: Jon Maloy Date: Wed, 10 Oct 2018 17:50:23 +0200 > From: Parthasarathy Bhuvaragan > > In tipc_sk_filter_rcv(), when we detect protocol messages with error we > call tipc_sk_conn_proto_rcv() and let it reset the connection and notify > the socket by calling sk->sk_state_change(). > >

Re: [tipc-discussion] [net 1/1] tipc: set link tolerance correctly in broadcast link

From: Jon Maloy Date: Wed, 10 Oct 2018 17:34:01 +0200 > In the patch referred to below we added link tolerance as an additional > criteria for declaring broadcast transmission "stale" and resetting the > affected links. > > However, the 'tolerance' field of the broadcast link is never set, and

Re: [tipc-discussion] [net 1/1] tipc: fix failover problem

From: Jon Maloy Date: Wed, 26 Sep 2018 21:00:54 +0200 > From: LUU Duc Canh > > We see the following scenario: > 1) Link endpoint B on node 1 discovers that its peer endpoint is gone. >Since there is a second working link, failover procedure is started. > 2) Link endpoint A on node 1 sends

Re: [tipc-discussion] [net-next 0/5] tipc: make connection setup more robust

From: Jon Maloy Date: Fri, 28 Sep 2018 20:23:17 +0200 > In this series we make a few improvements to the connection setup and > probing mechanism, culminating in the last commit where we make it > possible for a client socket to make multiple setup attempts in case > it encounters receive

Re: [tipc-discussion] [net 1/1] tipc: reset bearer if device carrier not ok

From: Jon Maloy Date: Tue, 25 Sep 2018 21:56:57 +0200 > From: Parthasarathy Bhuvaragan > > If we detect that under lying carrier detects errors and goes down, > we reset the bearer. > > Signed-off-by: Parthasarathy Bhuvaragan > > Signed-off-by: Jon Maloy Applied.

Re: [tipc-discussion] [net 1/1] tipc: lock wakeup & inputq at tipc_link_reset()

From: Jon Maloy Date: Tue, 25 Sep 2018 22:09:10 +0200 > From: Parthasarathy Bhuvaragan > > In tipc_link_reset() we copy the wakeup queue to input queue using > skb_queue_splice_init(link->wakeupq, link->inputq). > This is performed without holding any locks. The lists might be > simultaneously

Re: [tipc-discussion] [net 1/1] tipc: fix flow control accounting for implicit connect

From: Jon Maloy Date: Tue, 25 Sep 2018 18:21:58 +0200 > From: Parthasarathy Bhuvaragan > > In the case of implicit connect message with data > 1K, the flow > control accounting is incorrect. At this state, the socket does not > know the peer nodes capability and falls back to legacy flow

Re: [tipc-discussion] [Patch net] tipc: check return value of __tipc_dump_start()

From: Cong Wang Date: Tue, 11 Sep 2018 15:12:17 -0700 > When __tipc_dump_start() fails with running out of memory, > we have no reason to continue, especially we should avoid > calling tipc_dump_done(). > > Fixes: 8f5c5fcf3533 ("tipc: call start and done ops directly in >

Re: [tipc-discussion] [Patch net v3] tipc: call start and done ops directly in __tipc_nl_compat_dumpit()

From: Cong Wang Date: Tue, 4 Sep 2018 14:54:55 -0700 > __tipc_nl_compat_dumpit() uses a netlink_callback on stack, > so the only way to align it with other ->dumpit() call path > is calling tipc_dump_start() and tipc_dump_done() directly > inside it. Otherwise ->dumpit() would always get NULL

Re: [tipc-discussion] [Patch net] tipc: orphan sock in tipc_release()

From: Cong Wang Date: Mon, 3 Sep 2018 19:12:41 -0700 > Before we unlock the sock in tipc_release(), we have to > detach sk->sk_socket from sk, otherwise a parallel > tipc_sk_fill_sock_diag() could stil read it after we > free this socket. > > Fixes: c30b70deb5f4 ("tipc: implement socket

Re: [tipc-discussion] [PATCH net-next 1/2] tipc: correct spelling errors for struct tipc_bc_base's comment

From: Zhenbo Gao Date: Mon, 3 Sep 2018 16:36:45 +0800 > Trivial fix for two spelling mistakes. > > Signed-off-by: Zhenbo Gao > Reviewed-by: Ying Xue Applied. -- Check out the vibrant tech community on one of the

Re: [tipc-discussion] [PATCH net-next] tipc: correct structure parameter comments for topsrv

From: Zhenbo Gao Date: Mon, 3 Sep 2018 14:08:40 +0800 > Remove the following obsolete parameter comments of tipc_topsrv struct: > @rcvbuf_cache > @tipc_conn_new > @tipc_conn_release > @tipc_conn_recvmsg > @imp > @type > > Add the comments for the missing parameters below of

Re: [tipc-discussion] [Patch net] tipc: switch to rhashtable iterator

From: Cong Wang Date: Fri, 24 Aug 2018 12:28:06 -0700 > syzbot reported a use-after-free in tipc_group_fill_sock_diag(), > where tipc_group_fill_sock_diag() still reads tsk->group meanwhile > tipc_group_delete() just deletes it in tipc_release(). > > tipc_nl_sk_walk() aims to lock this sock

Re: [tipc-discussion] [PATCH] tipc: fix an interrupt unsafe locking scenario

From: Ying Xue Date: Tue, 7 Aug 2018 15:52:32 +0800 > Commit 9faa89d4ed9d ("tipc: make function tipc_net_finalize() thread > safe") tries to make it thread safe to set node address, so it uses > node_list_lock lock to serialize the whole process of setting node > address in tipc_net_finalize().

Re: [tipc-discussion] [PATCH] net/tipc: remove redundant variables 'tn' and 'oport'

From: Colin King Date: Tue, 31 Jul 2018 17:01:37 +0100 > From: Colin Ian King > > Variables 'tn' and 'oport' are being assigned but are never used hence > they are redundant and can be removed. > > Cleans up clang warnings: > warning: variable 'oport' set but not used

Re: [tipc-discussion] [PATCH] net: tipc: name_table: Replace GFP_ATOMIC with GFP_KERNEL in tipc_nametbl_init()

From: Jia-Ju Bai Date: Fri, 27 Jul 2018 17:28:25 +0800 > tipc_nametbl_init() is never called in atomic context. > It calls kzalloc() with GFP_ATOMIC, which is not necessary. > GFP_ATOMIC can be replaced with GFP_KERNEL. > > This is found by a static analysis tool named DCNS written by myself. >

Re: [tipc-discussion] [PATCH] net: tipc: bcast: Replace GFP_ATOMIC with GFP_KERNEL in tipc_bcast_init()

From: Jia-Ju Bai Date: Fri, 27 Jul 2018 17:31:35 +0800 > tipc_bcast_init() is never called in atomic context. > It calls kzalloc() with GFP_ATOMIC, which is not necessary. > GFP_ATOMIC can be replaced with GFP_KERNEL. > > This is found by a static analysis tool named DCNS written by myself. >

Re: [tipc-discussion] [PATCH net-next] tipc: add missing dev_put() on error in tipc_enable_l2_media

From: YueHaibing Date: Wed, 25 Jul 2018 18:00:49 +0800 > when tipc_own_id failed to obtain node identity,dev_put should > be call before return -EINVAL. > > Fixes: 682cd3cf946b ("tipc: confgiure and apply UDP bearer MTU on running > links") > Signed-off-by: YueHaibing Applied to net-next,

Re: [tipc-discussion] [PATCH net-next] tipc: make some functions static

From: YueHaibing Date: Thu, 19 Jul 2018 17:16:59 +0800 > Fixes the following sparse warnings: > > net/tipc/link.c:376:5: warning: symbol 'link_bc_rcv_gap' was not declared. > Should it be static? > net/tipc/link.c:823:6: warning: symbol 'link_prepare_wakeup' was not > declared. Should it be

Re: [tipc-discussion] [net-next 1/1] tipc: make link capability update thread safe

From: Jon Maloy Date: Wed, 18 Jul 2018 19:50:06 +0200 > The commit referred to below introduced an update of the link > capabilities field that is not safe. Given the recently added > feature to remove idle node and link items after 5 minutes, there > is a small risk that the update will happen

Re: [tipc-discussion] [PATCH net-next] tipc: remove unused tipc_group_size

From: YueHaibing Date: Tue, 17 Jul 2018 22:11:23 +0800 > After commit eb929a91b213 ("tipc: improve poll() for group member socket"), > it is no longer used. > > Signed-off-by: YueHaibing Applied. -- Check out the

Re: [tipc-discussion] [PATCH net-next] tipc: remove unused tipc_link_is_active

From: YueHaibing Date: Tue, 17 Jul 2018 21:58:46 +0800 > tipc_link_is_active is no longer used and can be removed. > > Signed-off-by: YueHaibing Applied. -- Check out the vibrant tech community on one of the world's

Re: [tipc-discussion] [net-next 0/2] tipc: make link protocol more resilient

From: Jon Maloy Date: Tue, 10 Jul 2018 01:07:34 +0200 > These two commits make the link ptotocol more resilient to > infrastructures with frequent packet duplication and long delays. Series applied, thanks Jon. --

Re: [tipc-discussion] [net-next 1/1] tipc: extend link reset criteria for stale packet retransmission

From: Jon Maloy Date: Fri, 6 Jul 2018 15:22:36 +0200 > Currently a link is declared stale and reset if there has been 100 > repeated attempts to retransmit the same packet. However, in certain > infrastructures we see that packet (NACK) duplicates and delays may > cause such retransmit attempts

Re: [tipc-discussion] [net 0/4] tipc: fixes in duplicate address discovery function

From: Jon Maloy Date: Fri, 6 Jul 2018 20:10:02 +0200 > commit 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address > hash values") introduced new functionality that has turned out to > contain several bugs and weaknesses. > > We address those in this series. Series applied and queued

Re: [tipc-discussion] [PATCH] tipc: mark expected switch fall-throughs

From: "Gustavo A. R. Silva" Date: Wed, 4 Jul 2018 16:13:59 -0500 > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Warning level 2 was used: -Wimplicit-fallthrough=2 > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [tipc-discussion] [net-next 1/1] tipc: Auto removal of peer down node instance

From: GhantaKrishnamurthy MohanKrishna Date: Fri, 29 Jun 2018 13:23:41 +0200 > A peer node is considered down if there are no > active links (or) lost contact to the node. In current implementation, > a peer node instance is deleted either if > > a) TIPC module is removed (or) > b) Application

Re: [tipc-discussion] [net-next 1/1] tipc: extend sock diag for group communication

From: GhantaKrishnamurthy MohanKrishna Date: Fri, 29 Jun 2018 13:26:18 +0200 > This commit extends the existing TIPC socket diagnostics framework > for information related to TIPC group communication. > > Acked-by: Ying Xue > Acked-by: Jon Maloy > Signed-off-by: GhantaKrishnamurthy

Re: [tipc-discussion] [net-next 1/1] tipc: optimize function tipc_node_timeout()

From: Jon Maloy Date: Thu, 28 Jun 2018 22:39:25 +0200 > From: Tung Nguyen > > In single-link usage, the function tipc_node_timeout() still iterates > over the whole link array to handle each link. Given that the maximum > number of bearers are 3, there are 2 redundant iterations with lock >

Re: [tipc-discussion] [net-next 1/1] tipc: eliminate buffer cloning in function tipc_msg_extract()

From: Jon Maloy Date: Thu, 28 Jun 2018 22:25:04 +0200 > From: Tung Nguyen > > The function tipc_msg_extract() is using skb_clone() to clone inner > messages from a message bundle buffer. Although this method is safe, > it has an undesired effect that each buffer clone inherits the > true-size

Re: [tipc-discussion] [PATCH net-next] tipc: eliminate complaint of KMSAN uninit-value in tipc_conn_rcv_sub

From: Ying Xue Date: Fri, 18 May 2018 19:50:55 +0800 > As variable s of struct tipc_subscr type is not initialized > in tipc_conn_rcv_from_sock() before it is used in tipc_conn_rcv_sub(), > KMSAN reported the following uninit-value type complaint: I agree with others

Re: [tipc-discussion] [PATCH net] tipc: eliminate KMSAN uninit-value in strcmp complaint

From: Ying Xue Date: Tue, 8 May 2018 21:44:06 +0800 > When we get link properties through netlink interface with > tipc_nl_node_get_link(), we don't validate TIPC_NLA_LINK_NAME > attribute at all, instead we directly use it. As a consequence, > KMSAN detected the

Re: [tipc-discussion] KMSAN: uninit-value in strcmp

From: syzbot Date: Thu, 03 May 2018 11:44:02 -0700 > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x185/0x1d0 lib/dump_stack.c:53 > kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067 > __msan_warning_32+0x6c/0xb0

Re: [tipc-discussion] [net-next 1/1] tipc: introduce ioctl for fetching node identity

From: Jon Maloy Date: Wed, 25 Apr 2018 19:29:36 +0200 > After the introduction of a 128-bit node identity it may be difficult > for a user to correlate between this identity and the generated node > hash address. > > We now try to make this easier by introducing a new

Re: [tipc-discussion] [net 1/1] tipc: fix bug in function tipc_nl_node_dump_monitor

From: Jon Maloy Date: Wed, 25 Apr 2018 18:29:25 +0200 > Commit 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor > summary") intended to fix a problem with user tool looping when max > number of bearers are enabled. > > Unfortunately, the wrong version of

Re: [tipc-discussion] [net-next 0/3] tipc: Confgiuration of MTU for media UDP

From: GhantaKrishnamurthy MohanKrishna Date: Thu, 19 Apr 2018 11:06:17 +0200 > Systematic measurements have shown that an emulated MTU of 14k for > UDP bearers is the optimal value for maximal throughput. Accordingly, > the default MTU of UDP

Re: [tipc-discussion] [net 1/1] tipc: fix infinite loop when dumping link monitor summary

From: Jon Maloy Date: Tue, 17 Apr 2018 21:58:27 +0200 > From: Tung Nguyen > > When configuring the number of used bearers to MAX_BEARER and issuing > command "tipc link monitor summary", the command enters infinite loop > in user space. >

Re: [tipc-discussion] [net 1/1] tipc: fix use-after-free in tipc_nametbl_stop

From: Jon Maloy Date: Tue, 17 Apr 2018 21:25:42 +0200 > When we delete a service item in tipc_nametbl_stop() we loop over > all service ranges in the service's RB tree, and for each service > range we loop over its pertaining publications while calling >

Re: [tipc-discussion] [net 1/1] tipc: fix missing initializer in tipc_sendmsg()

From: Jon Maloy Date: Thu, 12 Apr 2018 01:15:48 +0200 > The stack variable 'dnode' in __tipc_sendmsg() may theoretically > end up tipc_node_get_mtu() as an unitilalized variable. > > We fix this by intializing the variable at declaration. We also add > a default else

Re: [tipc-discussion] [net 1/1] tipc: fix unbalanced reference counter

From: Jon Maloy Date: Wed, 11 Apr 2018 22:52:09 +0200 > When a topology subscription is created, we may encounter (or KASAN > may provoke) a failure to create a corresponding service instance in > the binding table. Instead of letting the tipc_nametbl_subscribe() > report

Re: [tipc-discussion] [net-next 1/1] tipc: Fix namespace violation in tipc_sk_fill_sock_diag

From: GhantaKrishnamurthy MohanKrishna Date: Wed, 4 Apr 2018 14:49:47 +0200 > To fetch UID info for socket diagnostics, we determine the > namespace of user context using tipc socket instance. This > may cause namespace violation, as the kernel

Re: [tipc-discussion] [net-next 1/1] tipc: Fix missing list initializations in struct tipc_subscription

From: Jon Maloy Date: Tue, 3 Apr 2018 19:11:19 +0200 > When an item of struct tipc_subscription is created, we fail to > initialize the two lists aggregated into the struct. This has so far > never been a problem, since the items are just added to a root > object by

Re: [tipc-discussion] [PATCH] tipc: avoid possible string overflow

From: Arnd Bergmann Date: Wed, 28 Mar 2018 16:02:04 +0200 > gcc points out that the combined length of the fixed-length inputs to > l->name is larger than the destination buffer size: > > net/tipc/link.c: In function 'tipc_link_create': > net/tipc/link.c:465:26: error: '%s'

Re: [tipc-discussion] [net-next 1/4] tipc: replace name table service range array with rb tree

From: Jon Maloy Date: Wed, 28 Mar 2018 16:58:20 +0200 > -/* > - * tipc_nametbl_publish - add name publication to network name tables > +/* tipc_nametbl_publish - add service binding to name table > */ > struct publication *tipc_nametbl_publish(struct net *net, u32

Re: [tipc-discussion] [PATCH net-next] tipc: tipc_node_create() can be static

From: Wei Yongjun Date: Mon, 26 Mar 2018 14:33:13 + > Fixes the following sparse warning: > > net/tipc/node.c:336:18: warning: > symbol 'tipc_node_create' was not declared. Should it be static? > > Signed-off-by: Wei Yongjun Applied.

Re: [tipc-discussion] [PATCH net-next] tipc: fix error handling in tipc_udp_enable()

From: Wei Yongjun Date: Mon, 26 Mar 2018 14:32:44 + > Release alloced resource before return from the error handling > case in tipc_udp_enable(), otherwise will cause memory leak. > > Fixes: 52dfae5c85a4 ("tipc: obtain node identity from interface by default") >

Re: [tipc-discussion] [RFC PATCH net-next] tipc: tipc_disc_addr_trial_msg() can be static

From: kbuild test robot Date: Sat, 24 Mar 2018 03:47:42 +0800 > Fixes: 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash > values") > Signed-off-by: Fengguang Wu Applied.

Re: [tipc-discussion] [net-next 0/8] tipc: introduce 128-bit auto-configurable node id

From: Jon Maloy Date: Thu, 22 Mar 2018 20:42:44 +0100 > We introduce a 128-bit free-format node identity as an alternative to > the legacy structured 32-bit node address. > > We also make configuration of this identity optional; if a bearer is > enabled without a

Re: [tipc-discussion] [net-next 0/3] tipc: socket diagnostics additions for AF_TIPC

From: GhantaKrishnamurthy MohanKrishna Date: Wed, 21 Mar 2018 14:37:42 +0100 > The following patchsets add socket diagnostics support for AF_TIPC by > using the sock diag framework. The patchset was created on top of > commit id: fb66cb0. Series

Re: [tipc-discussion] [net-next 0/5] tipc: obsolete zone concept

From: Jon Maloy Date: Thu, 15 Mar 2018 16:48:49 +0100 > Functionality related to the 'zone' concept was never implemented in > TIPC. In this series we eliminate the remaining traces of it in the > code, and can hence take a first step in reducing the footprint and >

Re: [tipc-discussion] [net-next 1/1] tipc: sockopt(TIPC_SO_RCVBUF) for setting receive buffer

From: Jon Maloy Date: Tue, 27 Feb 2018 20:47:09 +0100 > From: Hoang Le > > We introduce a set/getsockopt for setting socket receive buffer per > individual socket. This has turned out to sometimes be necessary for > anycast and multicast

Re: [tipc-discussion] [net 1/1] tipc: correct initial value for group congestion flag

From: Jon Maloy Date: Mon, 26 Feb 2018 20:14:04 +0100 > In commit 60c253069632 ("tipc: fix race between poll() and > setsockopt()") we introduced a pointer from struct tipc_group to the > 'group_is_connected' flag in struct tipc_sock, so that this field can > be checked

Re: [tipc-discussion] [net-next v2 1/1] tipc: avoid unnecessary copying of bundled messages

From: Jon Maloy Date: Thu, 15 Feb 2018 14:14:37 +0100 > A received sk buffer may contain dozens of smaller 'bundled' messages > which after extraction go each in their own direction. > > Unfortunately, when we extract those messages using skb_clone() each > of the

<    1   2   3   4   >