Date: Mon, 7 Jun 2010 18:29:10 +0000 (UTC) From: Randall Stewart <rrs@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/netinet sctp_indata.c Message-ID: <201006071829.o57ITYs2030679@repoman.freebsd.org>
index | next in thread | raw e-mail
rrs 2010-06-07 18:29:10 UTC
FreeBSD src repository
Modified files:
sys/netinet sctp_indata.c
Log:
SVN rev 208897 on 2010-06-07 18:29:10Z by rrs
This fixes a BUG in the handling of the cum-ack calculation.
We were only paying attention to the nr-mapping-array. Which
seems to make sense on the surface, by definition things
up to the cum-ack should be deliverable thus in the nr-mapping-array.
However (there is always a gotcha) thats not true when it
comes to large messages. The stack may hold the message
while re-assembling it not not deliver it based on several
thresholds. If that happens (which it would for smaller
large messages) then the cum-ack is figured wrong. We
now properly use both arrays in the cum-ack calculation.
MFC after: 1 week.
Revision Changes Path
1.83 +12 -7 src/sys/netinet/sctp_indata.c
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201006071829.o57ITYs2030679>