diff options
author | Jon Maloy <jon.maloy@ericsson.com> | 2017-12-29 19:48:02 +0100 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2018-01-02 21:52:07 -0500 |
commit | f9c935db8086231a35b7f5c2a53e3f1e10f388ee (patch) | |
tree | 29dabfb3413a022ecf3328491c103b19bf9e1b75 /drivers/net/ethernet/intel | |
parent | 71891e2dab6b55a870f8f7735e44a2963860b5c6 (diff) | |
download | linux-f9c935db8086231a35b7f5c2a53e3f1e10f388ee.tar.bz2 |
tipc: fix problems with multipoint-to-point flow control
In commit 04d7b574b245 ("tipc: add multipoint-to-point flow control") we
introduced a protocol for preventing buffer overflow when many group
members try to simultaneously send messages to the same receiving member.
Stress test of this mechanism has revealed a couple of related bugs:
- When the receiving member receives an advertisement REMIT message from
one of the senders, it will sometimes prematurely activate a pending
member and send it the remitted advertisement, although the upper
limit for active senders has been reached. This leads to accumulation
of illegal advertisements, and eventually to messages being dropped
because of receive buffer overflow.
- When the receiving member leaves REMITTED state while a received
message is being read, we miss to look at the pending queue, to
activate the oldest pending peer. This leads to some pending senders
being starved out, and never getting the opportunity to profit from
the remitted advertisement.
We fix the former in the function tipc_group_proto_rcv() by returning
directly from the function once it becomes clear that the remitting
peer cannot leave REMITTED state at that point.
We fix the latter in the function tipc_group_update_rcv_win() by looking
up and activate the longest pending peer when it becomes clear that the
remitting peer now can leave REMITTED state.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ethernet/intel')
0 files changed, 0 insertions, 0 deletions