linux/net/tipc, branch v3.8.10

tipc: refactor accept() code for improved readability

2012-12-07T22:23:24Z

In TIPC's accept() routine, there is a large block of code relating to initialization of a new socket, all within an if condition checking if the allocation succeeded. Here, we simply flip the check of the if, so that the main execution path stays at the same indentation level, which improves readability. If the allocation fails, we jump to an already existing exit label. Signed-off-by: Paul Gortmaker

tipc: add lock nesting notation to quiet lockdep warning

2012-12-07T22:23:23Z

TIPC accept() call grabs the socket lock on a newly allocated socket while holding the socket lock on an old socket. But lockdep worries that this might be a recursive lock attempt: [ INFO: possible recursive locking detected ] --------------------------------------------- kworker/u:0/6 is trying to acquire lock: (sk_lock-AF_TIPC){+.+.+.}, at: [] accept+0x15c/0x310 [tipc] but task is already holding lock: (sk_lock-AF_TIPC){+.+.+.}, at: [] accept+0x28/0x310 [tipc] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(sk_lock-AF_TIPC); lock(sk_lock-AF_TIPC); *** DEADLOCK *** May be due to missing lock nesting notation [...] Tell lockdep that this locking is safe by using lock_sock_nested(). This is similar to what was done in commit 5131a184a3458d9 for SCTP code ("SCTP: lock_sock_nested in sctp_sock_migrate"). Also note that this is isn't something that is seen normally, as it was uncovered with some experimental work-in-progress code not yet ready for mainline. So no need for stable backports or similar of this commit. Signed-off-by: Ying Xue Signed-off-by: Paul Gortmaker

tipc: eliminate connection setup for implied connect in recv_msg()

2012-12-07T22:23:22Z

As connection setup is now completed asynchronously in BH context, in the function filter_connect(), the corresponding code in recv_msg() becomes redundant. Signed-off-by: Ying Xue Signed-off-by: Jon Maloy Signed-off-by: Paul Gortmaker

tipc: introduce non-blocking socket connect

2012-12-07T22:23:21Z

TIPC has so far only supported blocking connect(), meaning that a call to connect() doesn't return until either the connection is fully established, or an error occurs. This has proved insufficient for many users, so we now introduce non-blocking connect(), analogous to how this is done in TCP and other protocols. With this feature, if a connection cannot be established instantly, connect() will return the error code "-EINPROGRESS". If the user later calls connect() again, he will either have the return code "-EALREADY" or "-EISCONN", depending on whether the connection has been established or not. The user must have explicitly set the socket to be non-blocking (SOCK_NONBLOCK or O_NONBLOCK, depending on method used), so unless for some reason they had set this already (the socket would anyway remain blocking in current TIPC) this change should be completely backwards compatible. It is also now possible to call select() or poll() to wait for the completion of a connection. An effect of the above is that the actual completion of a connection may now be performed asynchronously, independent of the calls from user space. Therefore, we now execute this code in BH context, in the function filter_rcv(), which is executed upon reception of messages in the socket. Signed-off-by: Ying Xue Signed-off-by: Jon Maloy [PG: minor refactoring for improved connect/disconnect function names] Signed-off-by: Paul Gortmaker

tipc: consolidate connection-oriented message reception in one function

2012-12-07T22:23:20Z

Handling of connection-related message reception is currently scattered around at different places in the code. This makes it harder to verify that things are handled correctly in all possible scenarios. So we consolidate the existing processing of connection-oriented message reception in a single routine. In the process, we convert the chain of if/else into a switch/case for improved readability. A cast on the socket_state in the switch is needed to avoid compile warnings on 32 bit, like "net/tipc/socket.c:1252:2: warning: case value ‘4294967295’ not in enumerated type". This happens because existing tipc code pseudo extends the default linux socket state values with: #define SS_LISTENING -1 /* socket is listening */ #define SS_READY -2 /* socket is connectionless */ It may make sense to add these as _positive_ values to the existing socket state enum list someday, vs. these already existing defines. Signed-off-by: Ying Xue Signed-off-by: Jon Maloy [PG: add cast to fix warning; remove returns from middle of switch] Signed-off-by: Paul Gortmaker

tipc: standardize across connect/disconnect function naming

2012-12-07T22:23:19Z

Currently we have tipc_disconnect and tipc_disconnect_port. It is not clear from the names alone, what they do or how they differ. It turns out that tipc_disconnect just deals with the port locking and then calls tipc_disconnect_port which does all the work. If we rename as follows: tipc_disconnect_port --> __tipc_disconnect then we will be following typical linux convention, where: __tipc_disconnect: "raw" function that does all the work. tipc_disconnect: wrapper that deals with locking and then calls the real core __tipc_disconnect function With this, the difference is immediately evident, and locking violations are more apt to be spotted by chance while working on, or even just while reading the code. On the connect side of things, we currently only have the single "tipc_connect2port" function. It does both the locking at enter/exit, and the core of the work. Pending changes will make it desireable to have the connect be a two part locking wrapper + worker function, just like the disconnect is already. Here, we make the connect look just like the updated disconnect case, for the above reason, and for consistency. In the process, we also get rid of the "2port" suffix that was on the original name, since it adds no descriptive value. On close examination, one might notice that the above connect changes implicitly move the call to tipc_link_get_max_pkt() to be within the scope of tipc_port_lock() protected region; when it was not previously. We don't see any issues with this, and it is in keeping with __tipc_connect doing the work and tipc_connect just handling the locking. Signed-off-by: Paul Gortmaker

tipc: change sk_receive_queue upper limit

2012-12-07T22:23:18Z

The sk_recv_queue upper limit for connectionless sockets has empirically turned out to be too low. When we double the current limit we get much fewer rejected messages and no noticable negative side-effects. Signed-off-by: Jon Maloy Signed-off-by: Paul Gortmaker

tipc: eliminate aggregate sk_receive_queue limit

2012-12-07T19:19:52Z

As a complement to the per-socket sk_recv_queue limit, TIPC keeps a global atomic counter for the sum of sk_recv_queue sizes across all tipc sockets. When incremented, the counter is compared to an upper threshold value, and if this is reached, the message is rejected with error code TIPC_OVERLOAD. This check was originally meant to protect the node against buffer exhaustion and general CPU overload. However, all experience indicates that the feature not only is redundant on Linux, but even harmful. Users run into the limit very often, causing disturbances for their applications, while removing it seems to have no negative effects at all. We have also seen that overall performance is boosted significantly when this bottleneck is removed. Furthermore, we don't see any other network protocols maintaining such a mechanism, something strengthening our conviction that this control can be eliminated. As a result, the atomic variable tipc_queue_size is now unused and so it can be deleted. There is a getsockopt call that used to allow reading it; we retain that but just return zero for maximum compatibility. Signed-off-by: Ying Xue Signed-off-by: Jon Maloy Cc: Neil Horman [PG: phase out tipc_queue_size as pointed out by Neil Horman] Signed-off-by: Paul Gortmaker

tipc: remove obsolete flush of stale reassembly buffer

2012-12-06T22:20:19Z

Each link instance has a periodic job checking if there is a stale ongoing message reassembly associated to the link. If no new fragment has been received during the last 4*[link_tolerance] period, it is assumed the missing fragment will never arrive. As a consequence, the reassembly buffer is discarded, and a gap in the message sequence occurs. This assumption is wrong. After we abandoned our ambition to develop packet routing for multi-cluster networks, only single-hop packet transfer remains as an option. For those, all packets are guaranteed to be delivered in sequence to the defragmentation layer. Any failure to achieve sequenced delivery will eventually lead to link reset, and the reassembly buffer will be flushed anyway. So we just remove this periodic check, which is now obsolete. Signed-off-by: Erik Hugne Acked-by: Ying Xue Signed-off-by: Jon Maloy [PG: also delete get/inc_timer count, since they are now unused] Signed-off-by: Paul Gortmaker

tipc: delete TIPC_ADVANCED Kconfig variable

2012-11-22T19:33:29Z

There used to be a time when TIPC had lots of Kconfig knobs the end user could alter, but they have all been made automatic or obsolete, with the exception of CONFIG_TIPC_PORTS. This previously existing set of options was all hidden under the TIPC_ADVANCED setting, which does not exist in any code, but only in Kconfig scope. Having this now, just to hide the one remaining "advanced" option no longer makes sense. Remove it. Also get rid of the ifdeffery in the TIPC code that allowed for TIPC_PORTS to be possibly undefined. Signed-off-by: Paul Gortmaker