aboutsummaryrefslogtreecommitdiffstats
path: root/net/tipc/socket.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2016-11-22 11:29:28 -0500
committerDavid S. Miller <davem@davemloft.net>2016-11-22 13:27:16 -0500
commitf9aa9dc7d2d00e6eb02168ffc64ef614b89d7998 (patch)
tree061b767ccf7d6955cc4fb921c230a787d194392e /net/tipc/socket.c
parent06b37b650cf826349677564cb0ff1560ed8e51fc (diff)
parent3b404a519815b9820f73f1ecf404e5546c9270ba (diff)
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
All conflicts were simple overlapping changes except perhaps for the Thunder driver. That driver has a change_mtu method explicitly for sending a message to the hardware. If that fails it returns an error. Normally a driver doesn't need an ndo_change_mtu method becuase those are usually just range changes, which are now handled generically. But since this extra operation is needed in the Thunder driver, it has to stay. However, if the message send fails we have to restore the original MTU before the change because the entire call chain expects that if an error is thrown by ndo_change_mtu then the MTU did not change. Therefore code is added to nicvf_change_mtu to remember the original MTU, and to restore it upon nicvf_update_hw_max_frs() failue. Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/tipc/socket.c')
-rw-r--r--net/tipc/socket.c48
1 files changed, 1 insertions, 47 deletions
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 22d92f0ec5ac..4916d8fea328 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1,7 +1,7 @@
1/* 1/*
2 * net/tipc/socket.c: TIPC socket API 2 * net/tipc/socket.c: TIPC socket API
3 * 3 *
4 * Copyright (c) 2001-2007, 2012-2015, Ericsson AB 4 * Copyright (c) 2001-2007, 2012-2016, Ericsson AB
5 * Copyright (c) 2004-2008, 2010-2013, Wind River Systems 5 * Copyright (c) 2004-2008, 2010-2013, Wind River Systems
6 * All rights reserved. 6 * All rights reserved.
7 * 7 *
@@ -127,54 +127,8 @@ static const struct proto_ops packet_ops;
127static const struct proto_ops stream_ops; 127static const struct proto_ops stream_ops;
128static const struct proto_ops msg_ops; 128static const struct proto_ops msg_ops;
129static struct proto tipc_proto; 129static struct proto tipc_proto;
130
131static const struct rhashtable_params tsk_rht_params; 130static const struct rhashtable_params tsk_rht_params;
132 131
133/*
134 * Revised TIPC socket locking policy:
135 *
136 * Most socket operations take the standard socket lock when they start
137 * and hold it until they finish (or until they need to sleep). Acquiring
138 * this lock grants the owner exclusive access to the fields of the socket
139 * data structures, with the exception of the backlog queue. A few socket
140 * operations can be done without taking the socket lock because they only
141 * read socket information that never changes during the life of the socket.
142 *
143 * Socket operations may acquire the lock for the associated TIPC port if they
144 * need to perform an operation on the port. If any routine needs to acquire
145 * both the socket lock and the port lock it must take the socket lock first
146 * to avoid the risk of deadlock.
147 *
148 * The dispatcher handling incoming messages cannot grab the socket lock in
149 * the standard fashion, since invoked it runs at the BH level and cannot block.
150 * Instead, it checks to see if the socket lock is currently owned by someone,
151 * and either handles the message itself or adds it to the socket's backlog
152 * queue; in the latter case the queued message is processed once the process
153 * owning the socket lock releases it.
154 *
155 * NOTE: Releasing the socket lock while an operation is sleeping overcomes
156 * the problem of a blocked socket operation preventing any other operations
157 * from occurring. However, applications must be careful if they have
158 * multiple threads trying to send (or receive) on the same socket, as these
159 * operations might interfere with each other. For example, doing a connect
160 * and a receive at the same time might allow the receive to consume the
161 * ACK message meant for the connect. While additional work could be done
162 * to try and overcome this, it doesn't seem to be worthwhile at the present.
163 *
164 * NOTE: Releasing the socket lock while an operation is sleeping also ensures
165 * that another operation that must be performed in a non-blocking manner is
166 * not delayed for very long because the lock has already been taken.
167 *
168 * NOTE: This code assumes that certain fields of a port/socket pair are
169 * constant over its lifetime; such fields can be examined without taking
170 * the socket lock and/or port lock, and do not need to be re-read even
171 * after resuming processing after waiting. These fields include:
172 * - socket type
173 * - pointer to socket sk structure (aka tipc_sock structure)
174 * - pointer to port structure
175 * - port reference
176 */
177
178static u32 tsk_own_node(struct tipc_sock *tsk) 132static u32 tsk_own_node(struct tipc_sock *tsk)
179{ 133{
180 return msg_prevnode(&tsk->phdr); 134 return msg_prevnode(&tsk->phdr);