2006-01-02 19:04:38 +01:00
|
|
|
|
2014-06-09 11:08:18 -05:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-03-12 11:31:09 -04:00
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-01-11 13:30:43 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-01-11 13:30:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-01-11 13:30:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-30 12:00:53 +00:00
|
|
|
|
2014-04-24 16:26:47 +02:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-13 21:35:11 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
2014-04-11 16:15:36 -04:00
|
|
|
|
2012-08-21 11:16:57 +08:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-02-07 18:18:01 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:09 -04:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-11-04 13:24:29 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
tipc: eliminate aggregate sk_receive_queue limit
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
[PG: phase out tipc_queue_size as pointed out by Neil Horman]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-27 06:15:27 -05:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2009-11-05 22:18:14 -08:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-06-25 23:47:18 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
2013-06-17 10:54:37 -04:00
|
|
|
|
2012-08-21 11:16:57 +08:00
|
|
|
|
|
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2008-05-12 15:42:28 -07:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-17 10:54:47 -04:00
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2013-10-18 07:23:16 +02:00
|
|
|
|
2011-11-04 13:24:29 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2013-01-20 23:30:08 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-04-06 15:56:14 +02:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2013-12-27 10:18:28 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2013-12-27 10:18:28 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2013-12-27 10:18:28 +08:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2013-12-27 10:18:28 +08:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2013-12-27 10:18:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-27 10:18:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
tipc: convert topology server to use new server facility
As the new TIPC server infrastructure has been introduced, we can
now convert the TIPC topology server to it. We get two benefits
from doing this:
1) It simplifies the topology server locking policy. In the
original locking policy, we placed one spin lock pointer in the
tipc_subscriber structure to reuse the lock of the subscriber's
server port, controlling access to members of tipc_subscriber
instance. That is, we only used one lock to ensure both
tipc_port and tipc_subscriber members were safely accessed.
Now we introduce another spin lock for tipc_subscriber structure
only protecting themselves, to get a finer granularity locking
policy. Moreover, the change will allow us to make the topology
server code more readable and maintainable.
2) It fixes a bug where sent subscription events may be lost when
the topology port is congested. Using the new service, the
topology server now queues sent events into an outgoing buffer,
and then wakes up a sender process which has been blocked in
workqueue context. The process will keep picking events from the
buffer and send them to their respective subscribers, using the
kernel socket interface, until the buffer is empty. Even if the
socket is congested during transmission there is no risk that
events may be dropped, since the sender process may block when
needed.
Some minor reordering of initialization is done, since we now
have a scenario where the topology server must be started after
socket initialization has taken place, as the former depends
on the latter. And overall, we see a simplification of the
TIPC subscriber code in making this changeover.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:40 -04:00
|
|
|
|
2013-06-17 10:54:41 -04:00
|
|
|
|
2013-12-27 10:18:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-02 15:49:40 -04:00
|
|
|
|
2013-12-27 10:18:28 +08:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2013-12-27 10:18:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-14 22:43:32 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2008-07-14 22:43:32 -07:00
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:32 +00:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2010-10-31 07:10:32 +00:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2008-07-14 22:43:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2010-11-30 12:01:03 +00:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-26 16:48:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-17 11:00:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-16 16:47:06 +02:00
|
|
|
|
2010-08-17 11:00:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-03-26 16:48:21 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2010-08-17 11:00:06 +00:00
|
|
|
|
2008-03-26 16:48:21 -07:00
|
|
|
|
2012-08-21 11:16:57 +08:00
|
|
|
|
2008-03-26 16:48:21 -07:00
|
|
|
|
2010-08-17 11:00:06 +00:00
|
|
|
|
2012-10-16 16:47:06 +02:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2012-10-16 16:47:06 +02:00
|
|
|
|
|
|
|
|
|
2010-08-17 11:00:06 +00:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2010-08-17 11:00:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-26 16:48:21 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-03-20 22:37:04 -08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-01-18 13:09:29 -05:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-06-25 23:41:47 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2014-01-17 09:50:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2014-01-17 09:50:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-06-25 23:43:57 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2014-03-12 11:31:13 -04:00
|
|
|
|
2014-01-17 22:53:15 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-01-17 09:50:05 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 23:49:06 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2013-01-31 21:51:47 +01:00
|
|
|
|
2010-04-20 17:58:24 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 23:44:57 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2006-06-25 23:44:57 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:05 +08:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:33 +00:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:13 -04:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
tipc: Avoid recomputation of outgoing message length
Rework TIPC's message sending routines to take advantage of the total
amount of data value passed to it by the kernel socket infrastructure.
This change eliminates the need for TIPC to compute the size of outgoing
messages itself, as well as the check for an oversize message in
tipc_msg_build(). In addition, this change warrants an explanation:
- res = send_packet(NULL, sock, &my_msg, 0);
+ res = send_packet(NULL, sock, &my_msg, bytes_to_send);
Previously, the final argument to send_packet() was ignored (since the
amount of data being sent was recalculated by a lower-level routine)
and we could just pass in a dummy value (0). Now that the
recalculation is being eliminated, the argument value being passed to
send_packet() is significant and we have to supply the actual amount
of data we want to send.
Signed-off-by: Allan Stephens <Allan.Stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-04-21 10:42:07 -05:00
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:32 +00:00
|
|
|
|
2014-03-12 11:31:13 -04:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
tipc: Avoid recomputation of outgoing message length
Rework TIPC's message sending routines to take advantage of the total
amount of data value passed to it by the kernel socket infrastructure.
This change eliminates the need for TIPC to compute the size of outgoing
messages itself, as well as the check for an oversize message in
tipc_msg_build(). In addition, this change warrants an explanation:
- res = send_packet(NULL, sock, &my_msg, 0);
+ res = send_packet(NULL, sock, &my_msg, bytes_to_send);
Previously, the final argument to send_packet() was ignored (since the
amount of data being sent was recalculated by a lower-level routine)
and we could just pass in a dummy value (0). Now that the
recalculation is being eliminated, the argument value being passed to
send_packet() is significant and we have to supply the actual amount
of data we want to send.
Signed-off-by: Allan Stephens <Allan.Stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-04-21 10:42:07 -05:00
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:32 +00:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2010-12-31 18:59:33 +00:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:13 -04:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:35 +00:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-01-17 09:50:05 +08:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2014-01-17 09:50:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-06-25 23:43:57 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2014-01-17 22:53:15 +01:00
|
|
|
|
2014-01-17 09:50:06 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2013-01-31 21:51:47 +01:00
|
|
|
|
2010-04-20 17:58:24 -04:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-01-17 09:50:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 05:53:15 -04:00
|
|
|
|
2014-01-17 09:50:06 +08:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-03-12 11:31:13 -04:00
|
|
|
|
2010-12-31 18:59:35 +00:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-01-17 09:50:06 +08:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-01-17 09:50:06 +08:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
2006-06-25 23:46:50 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-10 17:25:24 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-06-25 23:46:50 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2007-06-10 17:25:24 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2013-12-12 09:36:40 +08:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2013-12-27 10:09:39 +08:00
|
|
|
|
|
|
|
|
|
2013-12-12 09:36:40 +08:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-16 21:43:54 -07:00
|
|
|
|
2013-01-31 21:51:47 +01:00
|
|
|
|
2010-04-20 17:58:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 23:46:50 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-10-16 21:43:54 -07:00
|
|
|
|
|
|
|
|
|
2006-06-25 23:46:50 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2007-06-10 17:25:24 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2007-06-10 17:25:24 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:33 +00:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2007-06-10 17:25:24 -07:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-06-25 23:46:50 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-06-25 23:46:50 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
tipc: introduce non-blocking socket connect
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: minor refactoring for improved connect/disconnect function names]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-29 18:51:19 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-03-20 22:37:04 -08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-01-17 22:53:15 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2013-04-07 01:52:00 +00:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:32 +00:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-03-20 22:37:04 -08:00
|
|
|
|
2013-06-17 10:54:47 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 23:45:24 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:33 +00:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2010-12-31 18:59:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 23:45:24 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 23:45:24 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 23:45:24 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 23:45:24 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2010-12-31 18:59:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-23 15:55:12 -04:00
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-23 15:55:12 -04:00
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-06 14:40:18 +01:00
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-23 15:55:12 -04:00
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-05-23 15:55:12 -04:00
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-21 09:45:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:06:12 -07:00
|
|
|
|
2014-05-14 05:39:08 -04:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2010-08-17 11:00:04 +00:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-17 11:00:04 +00:00
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2012-04-30 15:29:02 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-05-23 15:55:12 -04:00
|
|
|
|
2014-01-17 09:50:07 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-21 09:45:40 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-02-21 09:45:40 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2011-02-21 09:45:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-02-21 09:45:40 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-21 09:45:40 -05:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-14 05:39:08 -04:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2009-11-29 16:55:45 -08:00
|
|
|
|
|
|
|
|
|
2010-08-17 11:00:04 +00:00
|
|
|
|
2009-11-29 16:55:45 -08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-06-25 23:48:22 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2012-08-21 11:16:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-11 16:15:36 -04:00
|
|
|
|
2012-08-21 11:16:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:09 -04:00
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
2014-03-12 11:31:09 -04:00
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
tipc: introduce non-blocking socket connect
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: minor refactoring for improved connect/disconnect function names]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-29 18:51:19 -05:00
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:09 -04:00
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:09 -04:00
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tipc: introduce non-blocking socket connect
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: minor refactoring for improved connect/disconnect function names]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-29 18:51:19 -05:00
|
|
|
|
|
|
|
|
|
tipc: set sk_err correctly when connection fails
Should a connect fail, if the publication/server is unavailable or
due to some other error, a positive value will be returned and errno
is never set. If the application code checks for an explicit zero
return from connect (success) or a negative return (failure), it
will not catch the error and subsequent send() calls will fail as
shown from the strace snippet below.
socket(0x1e /* PF_??? */, SOCK_SEQPACKET, 0) = 3
connect(3, {sa_family=0x1e /* AF_??? */, sa_data="\2\1\322\4\0\0\322\4\0\0\0\0\0\0"}, 16) = 111
sendto(3, "test", 4, 0, NULL, 0) = -1 EPIPE (Broken pipe)
The reason for this behaviour is that TIPC wrongly inverts error
codes set in sk_err.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-08-28 09:29:58 +02:00
|
|
|
|
tipc: introduce non-blocking socket connect
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: minor refactoring for improved connect/disconnect function names]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-29 18:51:19 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
tipc: introduce non-blocking socket connect
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: minor refactoring for improved connect/disconnect function names]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-29 18:51:19 -05:00
|
|
|
|
|
|
|
|
|
tipc: set sk_err correctly when connection fails
Should a connect fail, if the publication/server is unavailable or
due to some other error, a positive value will be returned and errno
is never set. If the application code checks for an explicit zero
return from connect (success) or a negative return (failure), it
will not catch the error and subsequent send() calls will fail as
shown from the strace snippet below.
socket(0x1e /* PF_??? */, SOCK_SEQPACKET, 0) = 3
connect(3, {sa_family=0x1e /* AF_??? */, sa_data="\2\1\322\4\0\0\322\4\0\0\0\0\0\0"}, 16) = 111
sendto(3, "test", 4, 0, NULL, 0) = -1 EPIPE (Broken pipe)
The reason for this behaviour is that TIPC wrongly inverts error
codes set in sk_err.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-08-28 09:29:58 +02:00
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
tipc: introduce non-blocking socket connect
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: minor refactoring for improved connect/disconnect function names]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-29 18:51:19 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 23:30:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-17 10:54:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 23:30:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-12 09:36:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 23:30:09 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2013-01-20 23:30:09 +01:00
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2012-04-26 18:13:08 -04:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2010-12-31 18:59:25 +00:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2012-11-29 18:39:14 -05:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 23:30:09 +01:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2013-01-20 23:30:09 +01:00
|
|
|
|
2013-10-18 07:23:16 +02:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2013-01-20 23:30:09 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-04-11 16:15:36 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
2014-06-09 11:08:18 -05:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
|
|
|
|
|
2014-06-09 11:08:18 -05:00
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:10 -04:00
|
|
|
|
2014-05-14 05:39:15 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-05-14 05:39:15 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-05-14 05:39:15 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
2014-05-14 05:39:15 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-05-14 05:39:15 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-05-14 05:39:15 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
tipc: compensate for double accounting in socket rcv buffer
The function net/core/sock.c::__release_sock() runs a tight loop
to move buffers from the socket backlog queue to the receive queue.
As a security measure, sk_backlog.len of the receiving socket
is not set to zero until after the loop is finished, i.e., until
the whole backlog queue has been transferred to the receive queue.
During this transfer, the data that has already been moved is counted
both in the backlog queue and the receive queue, hence giving an
incorrect picture of the available queue space for new arriving buffers.
This leads to unnecessary rejection of buffers by sk_add_backlog(),
which in TIPC leads to unnecessarily broken connections.
In this commit, we compensate for this double accounting by adding
a counter that keeps track of it. The function socket.c::backlog_rcv()
receives buffers one by one from __release_sock(), and adds them to the
socket receive queue. If the transfer is successful, it increases a new
atomic counter 'tipc_sock::dupl_rcvcnt' with 'truesize' of the
transferred buffer. If a new buffer arrives during this transfer and
finds the socket busy (owned), we attempt to add it to the backlog.
However, when sk_add_backlog() is called, we adjust the 'limit'
parameter with the value of the new counter, so that the risk of
inadvertent rejection is eliminated.
It should be noted that this change does not invalidate the original
purpose of zeroing 'sk_backlog.len' after the full transfer. We set an
upper limit for dupl_rcvcnt, so that if a 'wild' sender (i.e., one that
doesn't respect the send window) keeps pumping in buffers to
sk_add_backlog(), he will eventually reach an upper limit,
(2 x TIPC_CONN_OVERLOAD_LIMIT). After that, no messages can be added
to the backlog, and the connection will be broken. Ordinary, well-
behaved senders will never reach this buffer limit at all.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 05:39:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-14 05:39:15 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-05-14 05:39:15 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-05-14 05:39:15 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-05-14 05:39:15 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:03 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2008-04-15 00:20:37 -07:00
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:03 +08:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:20:37 -07:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:20:37 -07:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:20:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:03 +08:00
|
|
|
|
tipc: introduce non-blocking socket connect
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: minor refactoring for improved connect/disconnect function names]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-29 18:51:19 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
tipc: introduce non-blocking socket connect
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: minor refactoring for improved connect/disconnect function names]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-29 18:51:19 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:03 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tipc: introduce non-blocking socket connect
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: minor refactoring for improved connect/disconnect function names]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-29 18:51:19 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:03 +08:00
|
|
|
|
2008-04-15 00:20:37 -07:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:20:37 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-07-06 06:01:13 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-06 14:40:18 +01:00
|
|
|
|
2014-01-17 09:50:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-12 11:31:09 -04:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
2014-03-12 11:31:08 -04:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
2014-01-17 09:50:04 +08:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-01-17 09:50:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2014-03-12 11:31:09 -04:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:11 -04:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
2014-03-12 11:31:09 -04:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 23:30:09 +01:00
|
|
|
|
2012-12-04 11:01:55 -05:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-03-06 15:05:38 -08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-06 15:05:38 -08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-30 15:29:02 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2013-10-18 07:23:16 +02:00
|
|
|
|
2011-11-04 13:24:29 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-29 09:38:15 -04:00
|
|
|
|
2013-01-20 23:30:08 +01:00
|
|
|
|
2012-10-29 09:38:15 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:33 +00:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-08-15 16:44:35 +02:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2011-05-26 13:44:34 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:33 +00:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-12 11:31:12 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2011-05-26 13:44:34 -04:00
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2010-12-31 18:59:32 +00:00
|
|
|
|
tipc: eliminate aggregate sk_receive_queue limit
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 <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
[PG: phase out tipc_queue_size as pointed out by Neil Horman]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-27 06:15:27 -05:00
|
|
|
|
2009-06-30 03:25:39 +00:00
|
|
|
|
2010-12-31 18:59:32 +00:00
|
|
|
|
2009-06-30 03:25:39 +00:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:22:02 -07:00
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:31 +00:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2010-12-31 18:59:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-04-24 16:26:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-10 10:55:35 +00:00
|
|
|
|
|
|
|
|
|
2008-02-07 18:18:01 -08:00
|
|
|
|
2010-12-31 18:59:32 +00:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-10 17:24:55 -07:00
|
|
|
|
2011-07-06 06:01:13 -04:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
2014-04-24 16:26:47 +02:00
|
|
|
|
2011-07-06 06:01:13 -04:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-19 10:44:56 +09:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-02-07 18:18:01 -08:00
|
|
|
|
2010-12-31 18:59:32 +00:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-10 17:24:55 -07:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-24 16:26:47 +02:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-19 10:44:56 +09:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-02-07 18:18:01 -08:00
|
|
|
|
2010-12-31 18:59:32 +00:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-10 17:24:55 -07:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-24 16:26:47 +02:00
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-19 10:44:56 +09:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-02-07 18:18:01 -08:00
|
|
|
|
2010-12-31 18:59:32 +00:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-17 10:54:37 -04:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
tipc: introduce new TIPC server infrastructure
TIPC has two internal servers, one providing a subscription
service for topology events, and another providing the
configuration interface. These servers have previously been running
in BH context, accessing the TIPC-port (aka native) API directly.
Apart from these servers, even the TIPC socket implementation is
partially built on this API.
As this API may simultaneously be called via different paths and in
different contexts, a complex and costly lock policiy is required
in order to protect TIPC internal resources.
To eliminate the need for this complex lock policiy, we introduce
a new, generic service API that uses kernel sockets for message
passing instead of the native API. Once the toplogy and configuration
servers are converted to use this new service, all code pertaining
to the native API can be removed. This entails a significant
reduction in code amount and complexity, and opens up for a complete
rework of the locking policy in TIPC.
The new service also solves another problem:
As the current topology server works in BH context, it cannot easily
be blocked when sending of events fails due to congestion. In such
cases events may have to be silently dropped, something that is
unacceptable. Therefore, the new service keeps a dedicated outbound
queue receiving messages from BH context. Once messages are
inserted into this queue, we will immediately schedule a work from a
special workqueue. This way, messages/events from the topology server
are in reality sent in process context, and the server can block
if necessary.
Analogously, there is a new workqueue for receiving messages. Once a
notification about an arriving message is received in BH context, we
schedule a work from the receive workqueue to do the job of
receiving the message in process context.
As both sending and receive messages are now finished in processes,
subscribed events cannot be dropped any more.
As of this commit, this new server infrastructure is built, but
not actually yet called by the existing TIPC code, but since the
conversion changes required in order to use it are significant,
the addition is kept here as a separate commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-17 10:54:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
