summaryrefslogtreecommitdiffstats
path: root/mm/page-writeback.c
diff options
context:
space:
mode:
authorJames Chapman <jchapman@katalix.com>2012-05-09 23:43:08 +0000
committerDavid S. Miller <davem@davemloft.net>2012-05-10 23:27:34 -0400
commit38d40b3f4e223336422b7e87cb483e758ef87e3a (patch)
tree59a1e49485c3fa596cf7538fd11c1aca589ad5ff /mm/page-writeback.c
parent1070b1b831404455d79d15fe94ae9216fb5f8ab4 (diff)
downloadlinux-38d40b3f4e223336422b7e87cb483e758ef87e3a.tar.gz
linux-38d40b3f4e223336422b7e87cb483e758ef87e3a.tar.bz2
linux-38d40b3f4e223336422b7e87cb483e758ef87e3a.zip
l2tp: fix reorder timeout recovery
When L2TP data packet reordering is enabled, packets are held in a queue while waiting for out-of-sequence packets. If a packet gets lost, packets will be held until the reorder timeout expires, when we are supposed to then advance to the sequence number of the next packet but we don't currently do so. As a result, the data channel is stuck because we are waiting for a packet that will never arrive - all packets age out and none are passed. The fix is to add a flag to the session context, which is set when the reorder timeout expires and tells the receive code to reset the next expected sequence number to that of the next packet in the queue. Tested in a production L2TP network with Starent and Nortel L2TP gear. Signed-off-by: James Chapman <jchapman@katalix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'mm/page-writeback.c')
0 files changed, 0 insertions, 0 deletions