linux/net/tipc/socket.c, branch v4.5

tipc: Revert "tipc: use existing sk_write_queue for outgoing packet chain"

2016-03-03T21:30:29Z

reverts commit 94153e36e709e ("tipc: use existing sk_write_queue for outgoing packet chain") In Commit 94153e36e709e, we assume that we fill & empty the socket's sk_write_queue within the same lock_sock() session. This is not true if the link is congested. During congestion, the socket lock is released while we wait for the congestion to cease. This implementation causes a nullptr exception, if the user space program has several threads accessing the same socket descriptor. Consider two threads of the same program performing the following: Thread1 Thread2 -------------------- ---------------------- Enter tipc_sendmsg() Enter tipc_sendmsg() lock_sock() lock_sock() Enter tipc_link_xmit(), ret=ELINKCONG spin on socket lock.. sk_wait_event() : release_sock() grab socket lock : Enter tipc_link_xmit(), ret=0 : release_sock() Wakeup after congestion lock_sock() skb = skb_peek(pktchain); !! TIPC_SKB_CB(skb)->wakeup_pending = tsk->link_cong; In this case, the second thread transmits the buffers belonging to both thread1 and thread2 successfully. When the first thread wakeup after the congestion it assumes that the pktchain is intact and operates on the skb's in it, which leads to the following exception: [2102.439969] BUG: unable to handle kernel NULL pointer dereference at 00000000000000d0 [2102.440074] IP: [] __tipc_link_xmit+0x2b0/0x4d0 [tipc] [2102.440074] PGD 3fa3f067 PUD 3fa6b067 PMD 0 [2102.440074] Oops: 0000 [#1] SMP [2102.440074] CPU: 2 PID: 244 Comm: sender Not tainted 3.12.28 #1 [2102.440074] RIP: 0010:[] [] __tipc_link_xmit+0x2b0/0x4d0 [tipc] [...] [2102.440074] Call Trace: [2102.440074] [] ? schedule+0x29/0x70 [2102.440074] [] ? tipc_node_unlock+0x46/0x170 [tipc] [2102.440074] [] tipc_link_xmit+0x51/0xf0 [tipc] [2102.440074] [] tipc_send_stream+0x11e/0x4f0 [tipc] [2102.440074] [] ? __wake_up_sync+0x20/0x20 [2102.440074] [] tipc_send_packet+0x1c/0x20 [tipc] [2102.440074] [] sock_sendmsg+0xa8/0xd0 [2102.440074] [] ? release_sock+0x145/0x170 [2102.440074] [] ___sys_sendmsg+0x3d8/0x3e0 [2102.440074] [] ? _raw_spin_unlock+0xe/0x10 [2102.440074] [] ? handle_mm_fault+0x6ca/0x9d0 [2102.440074] [] ? set_next_entity+0x85/0xa0 [2102.440074] [] ? _raw_spin_unlock_irq+0xe/0x20 [2102.440074] [] ? finish_task_switch+0x5c/0xc0 [2102.440074] [] ? __schedule+0x34c/0x950 [2102.440074] [] __sys_sendmsg+0x42/0x80 [2102.440074] [] SyS_sendmsg+0x12/0x20 [2102.440074] [] system_call_fastpath+0x16/0x1b In this commit, we maintain the skb list always in the stack. Signed-off-by: Parthasarathy Bhuvaragan Acked-by: Ying Xue Acked-by: Jon Maloy Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2015-12-04T02:09:12Z

Conflicts: drivers/net/ethernet/renesas/ravb_main.c kernel/bpf/syscall.c net/ipv4/ipmr.c All three conflicts were cases of overlapping changes. Signed-off-by: David S. Miller

net: Generalise wq_has_sleeper helper

2015-11-30T19:47:33Z

The memory barrier in the helper wq_has_sleeper is needed by just about every user of waitqueue_active. This patch generalises it by making it take a wait_queue_head_t directly. The existing helper is renamed to skwq_has_sleeper. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller

tipc: avoid packets leaking on socket receive queue

2015-11-24T04:45:15Z

Even if we drain receive queue thoroughly in tipc_release() after tipc socket is removed from rhashtable, it is possible that some packets are in flight because some CPU runs receiver and did rhashtable lookup before we removed socket. They will achieve receive queue, but nobody delete them at all. To avoid this leak, we register a private socket destructor to purge receive queue, meaning releasing packets pending on receive queue will be delayed until the last reference of tipc socket will be released. Signed-off-by: Ying Xue Signed-off-by: David S. Miller

tipc: introduce jumbo frame support for broadcast

2015-10-24T13:56:40Z

Until now, we have only been supporting a fix MTU size of 1500 bytes for all broadcast media, irrespective of their actual capability. We now make the broadcast MTU adaptable to the carrying media, i.e., we use the smallest MTU supported by any of the interfaces attached to TIPC. Signed-off-by: Jon Maloy Reviewed-by: Ying Xue Signed-off-by: David S. Miller

tipc: move bcast definitions to bcast.c

2015-10-24T13:56:24Z

Currently, a number of structure and function definitions related to the broadcast functionality are unnecessarily exposed in the file bcast.h. This obscures the fact that the external interface towards the broadcast link in fact is very narrow, and causes unnecessary recompilations of other files when anything changes in those definitions. In this commit, we move as many of those definitions as is currently possible to the file bcast.c. We also rename the structure 'tipc_bclink' to 'tipc_bc_base', both since the name does not correctly describe the contents of this struct, and will do so even less in the future, and because we want to use the term 'link' more appropriately in the functionality introduced later in this series. Finally, we rename a couple of functions, such as tipc_bclink_xmit() and others that will be kept in the future, to include the term 'bcast' instead. There are no functional changes in this commit. Signed-off-by: Jon Maloy Reviewed-by: Ying Xue Signed-off-by: David S. Miller

tipc: clean up socket layer message reception

2015-07-26T23:31:50Z

When a message is received in a socket, one of the call chains tipc_sk_rcv()->tipc_sk_enqueue()->filter_rcv()(->tipc_sk_proto_rcv()) or tipc_sk_backlog_rcv()->filter_rcv()(->tipc_sk_proto_rcv()) are followed. At each of these levels we may encounter situations where the message may need to be rejected, or a new message produced for transfer back to the sender. Despite recent improvements, the current code for doing this is perceived as awkward and hard to follow. Leveraging the two previous commits in this series, we now introduce a more uniform handling of such situations. We let each of the functions in the chain itself produce/reverse the message to be returned to the sender, but also perform the actual forwarding. This simplifies the necessary logics within each function. Reviewed-by: Ying Xue Signed-off-by: Jon Maloy Signed-off-by: David S. Miller

tipc: introduce new tipc_sk_respond() function

2015-07-26T23:31:50Z

Currently, we use the code sequence if (msg_reverse()) tipc_link_xmit_skb() at numerous locations in socket.c. The preparation of arguments for these calls, as well as the sequence itself, makes the code unecessarily complex. In this commit, we introduce a new function, tipc_sk_respond(), that performs this call combination. We also replace some, but not yet all, of these explicit call sequences with calls to the new function. Notably, we let the function tipc_sk_proto_rcv() use the new function to directly send out PROBE_REPLY messages, instead of deferring this to the calling tipc_sk_rcv() function, as we do now. Reviewed-by: Ying Xue Signed-off-by: Jon Maloy Signed-off-by: David S. Miller

tipc: let function tipc_msg_reverse() expand header when needed

2015-07-26T23:31:50Z

The shortest TIPC message header, for cluster local CONNECTED messages, is 24 bytes long. With this format, the fields "dest_node" and "orig_node" are optimized away, since they in reality are redundant in this particular case. However, the absence of these fields leads to code inconsistencies that are difficult to handle in some cases, especially when we need to reverse or reject messages at the socket layer. In this commit, we concentrate the handling of the absent fields to one place, by letting the function tipc_msg_reverse() reallocate the buffer and expand the header to 32 bytes when necessary. This means that the socket code now can assume that the two previously absent fields are present in the header when a message needs to be rejected. This opens up for some further simplifications of the socket code. Reviewed-by: Ying Xue Signed-off-by: Jon Maloy Signed-off-by: David S. Miller

tipc: make media xmit call outside node spinlock context

2015-07-21T03:41:15Z

Currently, message sending is performed through a deep call chain, where the node spinlock is grabbed and held during a significant part of the transmission time. This is clearly detrimental to overall throughput performance; it would be better if we could send the message after the spinlock has been released. In this commit, we do instead let the call revert on the stack after the buffer chain has been added to the transmission queue, whereafter clones of the buffers are transmitted to the device layer outside the spinlock scope. As a further step in our effort to separate the roles of the node and link entities we also move the function tipc_link_xmit() to node.c, and rename it to tipc_node_xmit(). Reviewed-by: Ying Xue Signed-off-by: Jon Maloy Signed-off-by: David S. Miller