#
8af535b6 |
| 28-Sep-2022 |
Yuan Can <yuancan@huawei.com> |
net/tipc: Remove unused struct distr_queue_item
After commit 09b5678c778f("tipc: remove dead code in tipc_net and relatives"), struct distr_queue_item is not used any more and can be removed as well
net/tipc: Remove unused struct distr_queue_item
After commit 09b5678c778f("tipc: remove dead code in tipc_net and relatives"), struct distr_queue_item is not used any more and can be removed as well.
Signed-off-by: Yuan Can <yuancan@huawei.com> Acked-by: Jon Maloy <jmaloy@redhat.com> Link: https://lore.kernel.org/r/20220928085636.71749-1-yuancan@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
c7223d68 |
| 09-Feb-2022 |
Jon Maloy <jmaloy@redhat.com> |
tipc: rate limit warning for received illegal binding update
It would be easy to craft a message containing an illegal binding table update operation. This is handled correctly by the code, but the
tipc: rate limit warning for received illegal binding update
It would be easy to craft a message containing an illegal binding table update operation. This is handled correctly by the code, but the corresponding warning printout is not rate limited as is should be. We fix this now.
Fixes: b97bf3fd8f6a ("[TIPC] Initial merge") Signed-off-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
5c834950 |
| 17-Mar-2021 |
Jon Maloy <jmaloy@redhat.com> |
tipc: remove some unnecessary warnings
We move some warning printouts to more strategic locations to avoid duplicates and yield more detailed information about the reported problem.
Signed-off-by:
tipc: remove some unnecessary warnings
We move some warning printouts to more strategic locations to avoid duplicates and yield more detailed information about the reported problem.
Signed-off-by: Jon Maloy <jmaloy@redhat.com> Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Hoang Le <hoang.h.le@dektech.com.au> Acked-by: Tung Nguyen <tung.q.nguyen@dektech.com.au> Acked-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
2c98da07 |
| 17-Mar-2021 |
Jon Maloy <jmaloy@redhat.com> |
tipc: simplify signature of tipc_nametbl_withdraw() functions
Following the principles of the preceding commits, we reduce the number of parameters passed along in tipc_sk_withdraw(), tipc_nametbl_w
tipc: simplify signature of tipc_nametbl_withdraw() functions
Following the principles of the preceding commits, we reduce the number of parameters passed along in tipc_sk_withdraw(), tipc_nametbl_withdraw() and associated functions.
Signed-off-by: Jon Maloy <jmaloy@redhat.com> Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Hoang Le <hoang.h.le@dektech.com.au> Acked-by: Tung Nguyen <tung.q.nguyen@dektech.com.au> Acked-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
a45ffa68 |
| 17-Mar-2021 |
Jon Maloy <jmaloy@redhat.com> |
tipc: simplify call signatures for publication creation
We simplify the call signatures for tipc_nametbl_insert_publ() and tipc_publ_create() so that fewer parameters are passed around.
Signed-off-
tipc: simplify call signatures for publication creation
We simplify the call signatures for tipc_nametbl_insert_publ() and tipc_publ_create() so that fewer parameters are passed around.
Signed-off-by: Jon Maloy <jmaloy@redhat.com> Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Hoang Le <hoang.h.le@dektech.com.au> Acked-by: Tung Nguyen <tung.q.nguyen@dektech.com.au> Acked-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
998d3907 |
| 17-Mar-2021 |
Jon Maloy <jmaloy@redhat.com> |
tipc: re-organize members of struct publication
In a future commit we will introduce more members to struct publication. In order to keep this structure comprehensible we now group some of its curre
tipc: re-organize members of struct publication
In a future commit we will introduce more members to struct publication. In order to keep this structure comprehensible we now group some of its current fields into the sub-structures where they really belong, - A struct tipc_service_range for the functional address the publication is representing. - A struct tipc_socket_addr for the socket bound to that service range.
We also rename the stack variable 'publ' to just 'p' in a few places. This is just as easy to understand in the given context, and keeps the number of wrapped code lines to a minimum.
There are no functional changes in this commit.
Signed-off-by: Jon Maloy <jmaloy@redhat.com> Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Hoang Le <hoang.h.le@dektech.com.au> Acked-by: Tung Nguyen <tung.q.nguyen@dektech.com.au> Acked-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
637b77fd |
| 29-Nov-2020 |
Randy Dunlap <rdunlap@infradead.org> |
net/tipc: fix all function Return: notation
Fix Return: kernel-doc notation in all net/tipc/ source files. Also keep ReST list notation intact for output formatting. Fix a few typos in comments.
Si
net/tipc: fix all function Return: notation
Fix Return: kernel-doc notation in all net/tipc/ source files. Also keep ReST list notation intact for output formatting. Fix a few typos in comments.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
cb67296e |
| 29-Nov-2020 |
Randy Dunlap <rdunlap@infradead.org> |
net/tipc: fix name_distr.c kernel-doc
Fix name_distr.c kernel-doc warnings in preparation for adding to the networking docbook.
../net/tipc/name_distr.c:55: warning: Function parameter or member 'i
net/tipc: fix name_distr.c kernel-doc
Fix name_distr.c kernel-doc warnings in preparation for adding to the networking docbook.
../net/tipc/name_distr.c:55: warning: Function parameter or member 'i' not described in 'publ_to_item' ../net/tipc/name_distr.c:55: warning: Function parameter or member 'p' not described in 'publ_to_item' ../net/tipc/name_distr.c:70: warning: Function parameter or member 'net' not described in 'named_prepare_buf' ../net/tipc/name_distr.c:70: warning: Function parameter or member 'type' not described in 'named_prepare_buf' ../net/tipc/name_distr.c:70: warning: Function parameter or member 'size' not described in 'named_prepare_buf' ../net/tipc/name_distr.c:70: warning: Function parameter or member 'dest' not described in 'named_prepare_buf' ../net/tipc/name_distr.c:88: warning: Function parameter or member 'net' not described in 'tipc_named_publish' ../net/tipc/name_distr.c:88: warning: Function parameter or member 'publ' not described in 'tipc_named_publish' ../net/tipc/name_distr.c:116: warning: Function parameter or member 'net' not described in 'tipc_named_withdraw' ../net/tipc/name_distr.c:116: warning: Function parameter or member 'publ' not described in 'tipc_named_withdraw' ../net/tipc/name_distr.c:147: warning: Function parameter or member 'net' not described in 'named_distribute' ../net/tipc/name_distr.c:147: warning: Function parameter or member 'seqno' not described in 'named_distribute' ../net/tipc/name_distr.c:199: warning: Function parameter or member 'net' not described in 'tipc_named_node_up' ../net/tipc/name_distr.c:199: warning: Function parameter or member 'dnode' not described in 'tipc_named_node_up' ../net/tipc/name_distr.c:199: warning: Function parameter or member 'capabilities' not described in 'tipc_named_node_up' ../net/tipc/name_distr.c:225: warning: Function parameter or member 'net' not described in 'tipc_publ_purge' ../net/tipc/name_distr.c:225: warning: Function parameter or member 'publ' not described in 'tipc_publ_purge' ../net/tipc/name_distr.c:225: warning: Function parameter or member 'addr' not described in 'tipc_publ_purge' ../net/tipc/name_distr.c:272: warning: Function parameter or member 'net' not described in 'tipc_update_nametbl' ../net/tipc/name_distr.c:272: warning: Function parameter or member 'i' not described in 'tipc_update_nametbl' ../net/tipc/name_distr.c:272: warning: Function parameter or member 'node' not described in 'tipc_update_nametbl' ../net/tipc/name_distr.c:272: warning: Function parameter or member 'dtype' not described in 'tipc_update_nametbl' ../net/tipc/name_distr.c:353: warning: Function parameter or member 'net' not described in 'tipc_named_rcv' ../net/tipc/name_distr.c:353: warning: Function parameter or member 'namedq' not described in 'tipc_named_rcv' ../net/tipc/name_distr.c:353: warning: Function parameter or member 'rcv_nxt' not described in 'tipc_named_rcv' ../net/tipc/name_distr.c:353: warning: Function parameter or member 'open' not described in 'tipc_named_rcv' ../net/tipc/name_distr.c:383: warning: Function parameter or member 'net' not described in 'tipc_named_reinit'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
09b5678c |
| 28-Oct-2020 |
Hoang Huu Le <hoang.h.le@dektech.com.au> |
tipc: remove dead code in tipc_net and relatives
dist_queue is no longer used since commit 37922ea4a310 ("tipc: permit overlapping service ranges in name table")
Acked-by: Jon Maloy <jmaloy@redhat.
tipc: remove dead code in tipc_net and relatives
dist_queue is no longer used since commit 37922ea4a310 ("tipc: permit overlapping service ranges in name table")
Acked-by: Jon Maloy <jmaloy@redhat.com> Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Hoang Huu Le <hoang.h.le@dektech.com.au> Link: https://lore.kernel.org/r/20201028032712.31009-1-hoang.h.le@dektech.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
7b50ee3d |
| 08-Oct-2020 |
Hoang Huu Le <hoang.h.le@dektech.com.au> |
tipc: fix NULL pointer dereference in tipc_named_rcv
In the function node_lost_contact(), we call __skb_queue_purge() without grabbing the list->lock. This can cause to a race-condition why processi
tipc: fix NULL pointer dereference in tipc_named_rcv
In the function node_lost_contact(), we call __skb_queue_purge() without grabbing the list->lock. This can cause to a race-condition why processing the list 'namedq' in calling path tipc_named_rcv()->tipc_named_dequeue().
[] BUG: kernel NULL pointer dereference, address: 0000000000000000 [] #PF: supervisor read access in kernel mode [] #PF: error_code(0x0000) - not-present page [] PGD 7ca63067 P4D 7ca63067 PUD 6c553067 PMD 0 [] Oops: 0000 [#1] SMP NOPTI [] CPU: 1 PID: 15 Comm: ksoftirqd/1 Tainted: G O 5.9.0-rc6+ #2 [] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS [...] [] RIP: 0010:tipc_named_rcv+0x103/0x320 [tipc] [] Code: 41 89 44 24 10 49 8b 16 49 8b 46 08 49 c7 06 00 00 00 [...] [] RSP: 0018:ffffc900000a7c58 EFLAGS: 00000282 [] RAX: 00000000000012ec RBX: 0000000000000000 RCX: ffff88807bde1270 [] RDX: 0000000000002c7c RSI: 0000000000002c7c RDI: ffff88807b38f1a8 [] RBP: ffff88807b006288 R08: ffff88806a367800 R09: ffff88806a367900 [] R10: ffff88806a367a00 R11: ffff88806a367b00 R12: ffff88807b006258 [] R13: ffff88807b00628a R14: ffff888069334d00 R15: ffff88806a434600 [] FS: 0000000000000000(0000) GS:ffff888079480000(0000) knlGS:0[...] [] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [] CR2: 0000000000000000 CR3: 0000000077320000 CR4: 00000000000006e0 [] Call Trace: [] ? tipc_bcast_rcv+0x9a/0x1a0 [tipc] [] tipc_rcv+0x40d/0x670 [tipc] [] ? _raw_spin_unlock+0xa/0x20 [] tipc_l2_rcv_msg+0x55/0x80 [tipc] [] __netif_receive_skb_one_core+0x8c/0xa0 [] process_backlog+0x98/0x140 [] net_rx_action+0x13a/0x420 [] __do_softirq+0xdb/0x316 [] ? smpboot_thread_fn+0x2f/0x1e0 [] ? smpboot_thread_fn+0x74/0x1e0 [] ? smpboot_thread_fn+0x14e/0x1e0 [] run_ksoftirqd+0x1a/0x40 [] smpboot_thread_fn+0x149/0x1e0 [] ? sort_range+0x20/0x20 [] kthread+0x131/0x150 [] ? kthread_unuse_mm+0xa0/0xa0 [] ret_from_fork+0x22/0x30 [] Modules linked in: veth tipc(O) ip6_udp_tunnel udp_tunnel [...] [] CR2: 0000000000000000 [] ---[ end trace 65c276a8e2e2f310 ]---
To fix this, we need to grab the lock of the 'namedq' list on both path calling.
Fixes: cad2929dc432 ("tipc: update a binding service via broadcast") Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: Hoang Huu Le <hoang.h.le@dektech.com.au> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
cad2929d |
| 17-Jun-2020 |
Hoang Huu Le <hoang.h.le@dektech.com.au> |
tipc: update a binding service via broadcast
Currently, updating binding table (add service binding to name table/withdraw a service binding) is being sent over replicast. However, if we are scaling
tipc: update a binding service via broadcast
Currently, updating binding table (add service binding to name table/withdraw a service binding) is being sent over replicast. However, if we are scaling up clusters to > 100 nodes/containers this method is less affection because of looping through nodes in a cluster one by one.
It is worth to use broadcast to update a binding service. This way, the binding table can be updated on all peer nodes in one shot.
Broadcast is used when all peer nodes, as indicated by a new capability flag TIPC_NAMED_BCAST, support reception of this message type.
Four problems need to be considered when introducing this feature. 1) When establishing a link to a new peer node we still update this by a unicast 'bulk' update. This may lead to race conditions, where a later broadcast publication/withdrawal bypass the 'bulk', resulting in disordered publications, or even that a withdrawal may arrive before the corresponding publication. We solve this by adding an 'is_last_bulk' bit in the last bulk messages so that it can be distinguished from all other messages. Only when this message has arrived do we open up for reception of broadcast publications/withdrawals.
2) When a first legacy node is added to the cluster all distribution will switch over to use the legacy 'replicast' method, while the opposite happens when the last legacy node leaves the cluster. This entails another risk of message disordering that has to be handled. We solve this by adding a sequence number to the broadcast/replicast messages, so that disordering can be discovered and corrected. Note however that we don't need to consider potential message loss or duplication at this protocol level.
3) Bulk messages don't contain any sequence numbers, and will always arrive in order. Hence we must exempt those from the sequence number control and deliver them unconditionally. We solve this by adding a new 'is_bulk' bit in those messages so that they can be recognized.
4) Legacy messages, which don't contain any new bits or sequence numbers, but neither can arrive out of order, also need to be exempt from the initial synchronization and sequence number check, and delivered unconditionally. Therefore, we add another 'is_not_legacy' bit to all new messages so that those can be distinguished from legacy messages and the latter delivered directly.
v1->v2: - fix warning issue reported by kbuild test robot <lkp@intel.com> - add santiy check to drop the publication message with a sequence number that is lower than the agreed synch point
Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Hoang Huu Le <hoang.h.le@dektech.com.au> Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
f73b1281 |
| 29-Oct-2019 |
Hoang Le <hoang.h.le@dektech.com.au> |
tipc: improve throughput between nodes in netns
Currently, TIPC transports intra-node user data messages directly socket to socket, hence shortcutting all the lower layers of the communication stack
tipc: improve throughput between nodes in netns
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.
- All nodes joining a cluster are supposed to have been be certified and authenticated by mechanisms outside TIPC. This is no different for nodes/namespaces on the same host; they have to auto discover each other using the attached interfaces, and establish links which are supervised via the regular link monitoring mechanism. Hence, a kernel local node has no other way to join a cluster than any other node, and have to obey to policies set in the IP or device layers of the stack.
- Only when a sender has established with 100% certainty that the peer node is located in a kernel local namespace does it choose to let user data messages, and only those, take the crossover path to the receiving node/namespace.
- If the receiving node/namespace is removed, its namespace pointer is invalidated at all peer nodes, and their neighbor link monitoring will eventually note that this node is gone.
- To ensure the "100% certainty" criteria, and prevent any possible spoofing, received discovery messages must contain a proof that the sender knows a common secret. We use the hash mix of the sending node/namespace for this purpose, since it can be accessed directly by all other namespaces in the kernel. Upon reception of a discovery message, the receiver checks this proof against all the local namespaces'hash_mix:es. If it finds a match, that, along with a matching node id and cluster id, this is deemed sufficient proof that the peer node in question is in a local namespace, and a wormhole can be opened.
- We should also consider that TIPC is intended to be a cluster local IPC mechanism (just like e.g. UNIX sockets) rather than a network protocol, and hence we think it can justified to allow it to shortcut the lower protocol layers.
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 <jon.maloy@ericsson.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
42dec1db |
| 03-Sep-2019 |
Xin Long <lucien.xin@gmail.com> |
tipc: add NULL pointer check before calling kfree_rcu
Unlike kfree(p), kfree_rcu(p, rcu) won't do NULL pointer check. When tipc_nametbl_remove_publ returns NULL, the panic below happens:
BUG: un
tipc: add NULL pointer check before calling kfree_rcu
Unlike kfree(p), kfree_rcu(p, rcu) won't do NULL pointer check. When tipc_nametbl_remove_publ returns NULL, the panic below happens:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000068 RIP: 0010:__call_rcu+0x1d/0x290 Call Trace: <IRQ> tipc_publ_notify+0xa9/0x170 [tipc] tipc_node_write_unlock+0x8d/0x100 [tipc] tipc_node_link_down+0xae/0x1d0 [tipc] tipc_node_check_dest+0x3ea/0x8f0 [tipc] ? tipc_disc_rcv+0x2c7/0x430 [tipc] tipc_disc_rcv+0x2c7/0x430 [tipc] ? tipc_rcv+0x6bb/0xf20 [tipc] tipc_rcv+0x6bb/0xf20 [tipc] ? ip_route_input_slow+0x9cf/0xb10 tipc_udp_recv+0x195/0x1e0 [tipc] ? tipc_udp_is_known_peer+0x80/0x80 [tipc] udp_queue_rcv_skb+0x180/0x460 udp_unicast_rcv_skb.isra.56+0x75/0x90 __udp4_lib_rcv+0x4ce/0xb90 ip_local_deliver_finish+0x11c/0x210 ip_local_deliver+0x6b/0xe0 ? ip_rcv_finish+0xa9/0x410 ip_rcv+0x273/0x362
Fixes: 97ede29e80ee ("tipc: convert name table read-write lock to RCU") Reported-by: Li Shuang <shuali@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
e654f9f5 |
| 15-Aug-2019 |
Jon Maloy <jon.maloy@ericsson.com> |
tipc: clean up skb list lock handling on send path
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 'xmit
tipc: clean up skb list lock handling on send path
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 <edumazet@google.com> Reported-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Reviewed-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
d12cffe9 |
| 11-Jul-2019 |
Chris Packham <chris.packham@alliedtelesis.co.nz> |
tipc: ensure head->lock is initialised
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 l
tipc: ensure head->lock is initialised
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 <chris.packham@alliedtelesis.co.nz> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
988f3f16 |
| 19-Oct-2018 |
Jon Maloy <jon.maloy@ericsson.com> |
tipc: eliminate message disordering during binding table update
We have seen the following race scenario: 1) named_distribute() builds a "bulk" message, containing a PUBLISH item for a certain pu
tipc: eliminate message disordering during binding table update
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) tipc_named_withdraw() removes the same publication from the list, bulds a WITHDRAW message and distributes it to all cluster nodes. 3) tipc_named_node_up(), which was calling named_distribute(), sends out the bulk message built under 1) 4) The WITHDRAW message arrives at the just detected node, finds no corresponding publication, and is dropped. 5) The PUBLISH item arrives at the same node, is added to its binding table, and remains there forever.
This arrival disordering was earlier taken care of by the backlog queue, originally added for a different purpose, which was removed in the commit referred to below, but we now need a different solution. In this commit, we replace the rcu lock protecting the 'cluster_scope' list with a regular RW lock which comprises even the sending of the bulk message. This both guarantees both the list integrity and the message sending order. We will later add a commit which cleans up this code further.
Note that this commit needs recently added commit d3092b2efca1 ("tipc: fix unsafe rcu locking when accessing publication list") to apply cleanly.
Fixes: 37922ea4a310 ("tipc: permit overlapping service ranges in name table") Reported-by: Tuong Lien Tong <tuong.t.lien@dektech.com.au> Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
d3092b2e |
| 12-Oct-2018 |
Tung Nguyen <tung.q.nguyen@dektech.com.au> |
tipc: fix unsafe rcu locking when accessing publication list
The binding table's 'cluster_scope' list is rcu protected to handle races between threads changing the list and those traversing the list
tipc: fix unsafe rcu locking when accessing publication list
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() uses the regular list_for_each() macro to traverse the said list. Likewise, the function tipc_named_withdraw() is removing items from the same list using the regular list_del() call. When these two functions execute in parallel we see occasional crashes.
This commit fixes this by adding the missing _rcu() suffixes.
Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
37922ea4 |
| 29-Mar-2018 |
Jon Maloy <jon.maloy@ericsson.com> |
tipc: permit overlapping service ranges in name table
With the new RB tree structure for service ranges it becomes possible to solve an old problem; - we can now allow overlapping service ranges in
tipc: permit overlapping service ranges in name table
With the new RB tree structure for service ranges it becomes possible to solve an old problem; - we can now allow overlapping service ranges in the table.
When inserting a new service range to the tree, we use 'lower' as primary key, and when necessary 'upper' as secondary key.
Since there may now be multiple service ranges matching an indicated 'lower' value, we must also add the 'upper' value to the functions used for removing publications, so that the correct, corresponding range item can be found.
These changes guarantee that a well-formed publication/withdrawal item from a peer node never will be rejected, and make it possible to eliminate the problematic backlog functionality we currently have for handling such cases.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
d50ccc2d |
| 22-Mar-2018 |
Jon Maloy <jon.maloy@ericsson.com> |
tipc: add 128-bit node identifier
We add a 128-bit node identity, as an alternative to the currently used 32-bit node address.
For the sake of compatibility and to minimize message header changes w
tipc: add 128-bit node identifier
We add a 128-bit node identity, as an alternative to the currently used 32-bit node address.
For the sake of compatibility and to minimize message header changes we retain the existing 32-bit address field. When not set explicitly by the user, this field will be filled with a hash value generated from the much longer node identity, and be used as a shorthand value for the latter.
We permit either the address or the identity to be set by configuration, but not both, so when the address value is set by a legacy user the corresponding 128-bit node identity is generated based on the that value.
Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
23fd3eac |
| 22-Mar-2018 |
Jon Maloy <jon.maloy@ericsson.com> |
tipc: remove direct accesses to own_addr field in struct tipc_net
As a preparation to changing the addressing structure of TIPC we replace all direct accesses to the tipc_net::own_addr field with th
tipc: remove direct accesses to own_addr field in struct tipc_net
As a preparation to changing the addressing structure of TIPC we replace all direct accesses to the tipc_net::own_addr field with the function dedicated for this, tipc_own_addr().
There are no changes to program logics in this commit.
Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
e50e73e1 |
| 15-Mar-2018 |
Jon Maloy <jon.maloy@ericsson.com> |
tipc: some name changes
We rename some lists and fields in struct publication both to make the naming more consistent and to better reflect their roles. We also update the descriptions of those list
tipc: some name changes
We rename some lists and fields in struct publication both to make the naming more consistent and to better reflect their roles. We also update the descriptions of those lists.
node_list -> local_publ cluster_list -> all_publ pport_list -> binding_sock ref -> port
There are no functional changes in this commit.
Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
935439cc |
| 15-Mar-2018 |
Jon Maloy <jon.maloy@ericsson.com> |
tipc: merge two lists in struct publication
The size of struct publication can be reduced further. Membership in lists 'nodesub_list' and 'local_list' is mutually exlusive, in that remote publicatio
tipc: merge two lists in struct publication
The size of struct publication can be reduced further. Membership in lists 'nodesub_list' and 'local_list' is mutually exlusive, in that remote publications use the former and local publications the latter. We replace the two lists with one single, named 'binding_node' which reflects what it really is.
Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
64a52b26 |
| 15-Mar-2018 |
Jon Maloy <jon.maloy@ericsson.com> |
tipc: remove zone publication list in name table
As a consequence of the previous commit we nan now eliminate zone scope related lists in the name table. We start with name_table::publ_list[3], whic
tipc: remove zone publication list in name table
As a consequence of the previous commit we nan now eliminate zone scope related lists in the name table. We start with name_table::publ_list[3], which can now be replaced with two lists, one for node scope publications and one for cluster scope publications.
Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
57d5f64d |
| 13-Jan-2017 |
Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com> |
tipc: allocate user memory with GFP_KERNEL flag
Until now, we allocate memory always with GFP_ATOMIC flag. When the system is under memory pressure and a user tries to send, the send fails due to lo
tipc: allocate user memory with GFP_KERNEL flag
Until now, we allocate memory always with GFP_ATOMIC flag. When the system is under memory pressure and a user tries to send, the send fails due to low memory. However, the user application can wait for free memory if we allocate it using GFP_KERNEL flag.
In this commit, we use allocate memory with GFP_KERNEL for all user allocation.
Reported-by: Rune Torgersen <runet@innovsys.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
06bd2b1e |
| 27-Oct-2016 |
Jon Paul Maloy <jon.maloy@ericsson.com> |
tipc: fix broadcast link synchronization problem
In commit 2d18ac4ba745 ("tipc: extend broadcast link initialization criteria") we tried to fix a problem with the initial synchronization of broadcas
tipc: fix broadcast link synchronization problem
In commit 2d18ac4ba745 ("tipc: extend broadcast link initialization criteria") we tried to fix a problem with the initial synchronization of broadcast link acknowledge values. Unfortunately that solution is not sufficient to solve the issue.
We have seen it happen that LINK_PROTOCOL/STATE packets with a valid non-zero unicast acknowledge number may bypass BCAST_PROTOCOL initialization, NAME_DISTRIBUTOR and other STATE packets with invalid broadcast acknowledge numbers, leading to premature opening of the broadcast link. When the bypassed packets finally arrive, they are inadvertently accepted, and the already correctly initialized acknowledge number in the broadcast receive link is overwritten by the invalid (zero) value of the said packets. After this the broadcast link goes stale.
We now fix this by marking the packets where we know the acknowledge value is or may be invalid, and then ignoring the acks from those.
To this purpose, we claim an unused bit in the header to indicate that the value is invalid. We set the bit to 1 in the initial BCAST_PROTOCOL synchronization packet and all initial ("bulk") NAME_DISTRIBUTOR packets, plus those LINK_PROTOCOL packets sent out before the broadcast links are fully synchronized.
This minor protocol update is fully backwards compatible.
Reported-by: John Thompson <thompa.atl@gmail.com> Tested-by: John Thompson <thompa.atl@gmail.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|