linux-toradex.git/net/tipc, branch v3.14.3

tipc: fix spinlock recursion bug for failed subscriptions

2014-03-24T19:36:56+00:00

If a topology event subscription fails for any reason, such as out
of memory, max number reached or because we received an invalid
request the correct behavior is to terminate the subscribers
connection to the topology server. This is currently broken and
produces the following oops:

[27.953662] tipc: Subscription rejected, illegal request
[27.955329] BUG: spinlock recursion on CPU#1, kworker/u4:0/6
[27.957066]  lock: 0xffff88003c67f408, .magic: dead4ead, .owner: kworker/u4:0/6, .owner_cpu: 1
[27.958054] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 3.14.0-rc6+ #5
[27.960230] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[27.960874] Workqueue: tipc_rcv tipc_recv_work [tipc]
[27.961430]  ffff88003c67f408 ffff88003de27c18 ffffffff815c0207 ffff88003de1c050
[27.962292]  ffff88003de27c38 ffffffff815beec5 ffff88003c67f408 ffffffff817f0a8a
[27.963152]  ffff88003de27c58 ffffffff815beeeb ffff88003c67f408 ffffffffa0013520
[27.964023] Call Trace:
[27.964292]  [] dump_stack+0x45/0x56
[27.964874]  [] spin_dump+0x8c/0x91
[27.965420]  [] spin_bug+0x21/0x26
[27.965995]  [] do_raw_spin_lock+0x116/0x140
[27.966631]  [] _raw_spin_lock_bh+0x15/0x20
[27.967256]  [] subscr_conn_shutdown_event+0x20/0xa0 [tipc]
[27.968051]  [] tipc_close_conn+0xa4/0xb0 [tipc]
[27.968722]  [] tipc_conn_terminate+0x1a/0x30 [tipc]
[27.969436]  [] subscr_conn_msg_event+0x1f2/0x2f0 [tipc]
[27.970209]  [] tipc_receive_from_sock+0x90/0xf0 [tipc]
[27.970972]  [] tipc_recv_work+0x29/0x50 [tipc]
[27.971633]  [] process_one_work+0x165/0x3e0
[27.972267]  [] worker_thread+0x119/0x3a0
[27.972896]  [] ? manage_workers.isra.25+0x2a0/0x2a0
[27.973622]  [] kthread+0xdf/0x100
[27.974168]  [] ? kthread_create_on_node+0x1a0/0x1a0
[27.974893]  [] ret_from_fork+0x7c/0xb0
[27.975466]  [] ? kthread_create_on_node+0x1a0/0x1a0

The recursion occurs when subscr_terminate tries to grab the
subscriber lock, which is already taken by subscr_conn_msg_event.
We fix this by checking if the request to establish a new
subscription was successful, and if not we initiate termination of
the subscriber after we have released the subscriber lock.

Signed-off-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: don't log disabled tasklet handler errors

2014-03-06T19:46:24+00:00

Failure to schedule a TIPC tasklet with tipc_k_signal because the
tasklet handler is disabled is not an error. It means TIPC is
currently in the process of shutting down. We remove the error
logging in this case.

Signed-off-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: fix memory leak during module removal

2014-03-06T19:46:24+00:00

When the TIPC module is removed, the tasklet handler is disabled
before all other subsystems. This will cause lingering publications
in the name table because the node_down tasklets responsible to
clean up publications from an unreachable node will never run.
When the name table is shut down, these publications are detected
and an error message is logged:
tipc: nametbl_stop(): orphaned hash chain detected
This is actually a memory leak, introduced with commit
993b858e37b3120ee76d9957a901cca22312ffaa ("tipc: correct the order
of stopping services at rmmod")

Instead of just logging an error and leaking memory, we free
the orphaned entries during nametable shutdown.

Signed-off-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: drop subscriber connection id invalidation

2014-03-06T19:46:23+00:00

When a topology server subscriber is disconnected, the associated
connection id is set to zero. A check vs zero is then done in the
subscription timeout function to see if the subscriber have been
shut down. This is unnecessary, because all subscription timers
will be cancelled when a subscriber terminates. Setting the
connection id to zero is actually harmful because id zero is the
identity of the topology server listening socket, and can cause a
race that leads to this socket being closed instead.

Signed-off-by: Erik Hugne 
Acked-by: Ying Xue 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: avoid to unnecessary process switch under non-block mode

2014-03-06T19:46:23+00:00

When messages are received via tipc socket under non-block mode,
schedule_timeout() is called in tipc_wait_for_rcvmsg(), that is,
the process of receiving messages will be scheduled once although
timeout value passed to schedule_timeout() is 0. The same issue
exists in accept()/wait_for_accept(). To avoid this unnecessary
process switch, we only call schedule_timeout() if the timeout
value is non-zero.

Signed-off-by: Ying Xue 
Reviewed-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: fix connection refcount leak

2014-03-06T19:46:23+00:00

When tipc_conn_sendmsg() calls tipc_conn_lookup() to query a
connection instance, its reference count value is increased if
it's found. But subsequently if it's found that the connection is
closed, the work of sending message is not queued into its server
send workqueue, and the connection reference count is not decreased.
This will cause a reference count leak. To reproduce this problem,
an application would need to open and closes topology server
connections with high intensity.

We fix this by immediately decrementing the connection reference
count if a send fails due to the connection being closed.

Signed-off-by: Ying Xue 
Acked-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: allow connection shutdown callback to be invoked in advance

2014-03-06T19:46:23+00:00

Currently connection shutdown callback function is called when
connection instance is released in tipc_conn_kref_release(), and
receiving packets and sending packets are running in different
threads. Even if connection is closed by the thread of receiving
packets, its shutdown callback may not be called immediately as
the connection reference count is non-zero at that moment. So,
although the connection is shut down by the thread of receiving
packets, the thread of sending packets doesn't know it. Before
its shutdown callback is invoked to tell the sending thread its
connection has been closed, the sending thread may deliver
messages by tipc_conn_sendmsg(), this is why the following error
information appears:

"Sending subscription event failed, no memory"

To eliminate it, allow connection shutdown callback function to
be called before connection id is removed in tipc_close_conn(),
which makes the sending thread know the truth in time that its
socket is closed so that it doesn't send message to it. We also
remove the "Sending XXX failed..." error reporting for topology
and config services.

Signed-off-by: Ying Xue 
Signed-off-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: make bearer set up in module insertion stage

2014-02-22T05:00:15+00:00

Accidentally a side effect is involved by commit 6e967adf7(tipc:
relocate common functions from media to bearer). Now tipc stack
handler of receiving packets from netdevices as well as netdevice
notification handler are registered when bearer is enabled rather
than tipc module initialization stage, but the two handlers are
both unregistered in tipc module exit phase. If tipc module is
inserted and then immediately removed, the following warning
message will appear:

"dev_remove_pack: ffffffffa0380940 not found"

This is because in module insertion stage tipc stack packet handler
is not registered at all, but in module exit phase dev_remove_pack()
needs to remove it. Of course, dev_remove_pack() cannot find tipc
protocol handler from the kernel protocol handler list so that the
warning message is printed out.

But if registering the two handlers is adjusted from enabling bearer
phase into inserting module stage, the warning message will be
eliminated. Due to this change, tipc_core_start_net() and
tipc_core_stop_net() can be deleted as well.

Reported-by: Wang Weidong 
Cc: Jon Maloy 
Cc: Erik Hugne 
Signed-off-by: Ying Xue 
Reviewed-by: Paul Gortmaker 
Signed-off-by: David S. Miller

tipc: remove all enabled flags from all tipc components

2014-02-22T05:00:15+00:00

When tipc module is inserted, many tipc components are initialized
one by one. During the initialization period, if one of them is
failed, tipc_core_stop() will be called to stop all components
whatever corresponding components are created or not. To avoid to
release uncreated ones, relevant components have to add necessary
enabled flags indicating whether they are created or not.

But in the initialization stage, if one component is unsuccessfully
created, we will just destroy successfully created components before
the failed component instead of all components. All enabled flags
defined in components, in turn, become redundant. Additionally it's
also unnecessary to identify whether table.types is NULL in
tipc_nametbl_stop() because name stable has been definitely created
successfully when tipc_nametbl_stop() is called.

Cc: Jon Maloy 
Cc: Erik Hugne 
Signed-off-by: Ying Xue 
Reviewed-by: Paul Gortmaker 
Signed-off-by: David S. Miller

tipc: fix message corruption bug for deferred packets

2014-02-13T21:35:05+00:00

If a packet received on a link is out-of-sequence, it will be
placed on a deferred queue and later reinserted in the receive
path once the preceding packets have been processed. The problem
with this is that it will be subject to the buffer adjustment from
link_recv_buf_validate twice. The second adjustment for 20 bytes
header space will corrupt the packet.

We solve this by tagging the deferred packets and bail out from
receive buffer validation for packets that have already been
subjected to this.

Signed-off-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller