linux.git/net/sctp/ulpqueue.c, branch v2.6.23

SCTP: properly clean up fragment and ordering queues during FWD-TSN.

2007-08-29T17:34:33+00:00

When we recieve a FWD-TSN (meaning the peer has abandoned the data),
we need to clean up any partially received messages that may be
hanging out on the re-assembly or re-ordering queues.  This is
a MUST requirement that was not properly done before.

Signed-off-by: Vlad Yasevich

[NET]: cleanup extra semicolons

2007-04-26T05:29:24+00:00

Spring cleaning time...

There seems to be a lot of places in the network code that have
extra bogus semicolons after conditionals.  Most commonly is a
bogus semicolon after: switch() { }

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller

[SCTP]: Implement SCTP_PARTIAL_DELIVERY_POINT option.

2007-04-26T05:28:00+00:00

This option induces partial delivery to run as soon
as the specified amount of data has been accumulated on
the association.  However, we give preference to fully
reassembled messages over PD messages.  In any case,
window and buffer is freed up.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

[SCTP]: Implement SCTP_FRAGMENT_INTERLEAVE socket option

2007-04-26T05:27:59+00:00

This option was introduced in draft-ietf-tsvwg-sctpsocket-13.  It
prevents head-of-line blocking in the case of one-to-many endpoint.
Applications enabling this option really must enable SCTP_SNDRCV event
so that they would know where the data belongs.  Based on an
earlier patch by Ivan Skytte Jørgensen.

Additionally, this functionality now permits multiple associations
on the same endpoint to enter Partial Delivery.  Applications should
be extra careful, when using this functionality, to track EOR indicators.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

[SCTP]: Do not interleave non-fragments when in partial delivery

2007-04-18T21:16:09+00:00

The way partial delivery is currently implemnted, it is possible to
intereleave a message (either from another steram, or unordered) that
is not part of partial delivery process.  The only way to this is for
a message to not be a fragment and be 'in order' or unorderd for a
given stream.  This will result in bypassing the reassembly/ordering
queues where things live duing partial delivery, and the
message will be delivered to the socket in the middle of partial delivery.

This is a two-fold problem, in that:
1.  the app now must check the stream-id and flags which it may not
be doing.
2.  this clearing partial delivery state from the association and results
in ulp hanging.

This patch is a band-aid over a much bigger problem in that we
don't do stream interleave.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

[SCTP]: Clean up stale data during association restart

2007-03-20T07:09:43+00:00

During association restart we may have stale data sitting
on the ULP queue waiting for ordering or reassembly.  This
data may cause severe problems if not cleaned up.  In particular
stale data pending ordering may cause problems with receive
window exhaustion if our peer has decided to restart the
association.

Signed-off-by: Vlad Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller

[NET] SCTP: Fix whitespace errors.

2007-02-11T07:20:11+00:00

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

[SCTP]: Fix receive buffer accounting.

2006-10-12T06:59:44+00:00

When doing receiver buffer accounting, we always used skb->truesize.
This is problematic when processing bundled DATA chunks because for
every DATA chunk that could be small part of one large skb, we would
charge the size of the entire skb.  The new approach is to store the
size of the DATA chunk we are accounting for in the sctp_ulpevent
structure and use that stored value for accounting.

Signed-off-by: Vlad Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller

[SCTP]: Prevent possible infinite recursion with multiple bundled DATA.

2006-05-06T00:03:49+00:00

There is a rare situation that causes lksctp to go into infinite recursion
and crash the system.  The trigger is a packet that contains at least the
first two DATA fragments of a message bundled together. The recursion is
triggered when the user data buffer is smaller that the full data message.
The problem is that we clone the skb for every fragment in the message.
When reassembling the full message, we try to link skbs from the "first
fragment" clone using the frag_list. However, since the frag_list is shared
between two clones in this rare situation, we end up setting the frag_list
pointer of the second fragment to point to itself.  This causes
sctp_skb_pull() to potentially recurse indefinitely.

Proposed solution is to make a copy of the skb when attempting to link
things using frag_list.

Signed-off-by: Vladislav Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller

[PATCH] gfp flags annotations - part 1

2005-10-08T22:00:57+00:00

 - added typedef unsigned int __nocast gfp_t;

 - replaced __nocast uses for gfp flags with gfp_t - it gives exactly
   the same warnings as far as sparse is concerned, doesn't change
   generated code (from gcc point of view we replaced unsigned int with
   typedef) and documents what's going on far better.

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds