Eric Lee / smarc-ti-linux-kernel

20 Mar, 2007

1 commit

  • 0b58a8114   [SCTP]: Clean up stale data during association restart ... Browse Code »

    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

    Vlad Yasevich
     

11 Feb, 2007

1 commit

12 Oct, 2006

1 commit

  • 331c4ee7f   [SCTP]: Fix receive buffer accounting. ... Browse Code »

    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

    Vlad Yasevich
     

06 May, 2006

1 commit

  • 672e7cca1   [SCTP]: Prevent possible infinite recursion with multiple bundled DATA. ... Browse Code »

    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

    Vladislav Yasevich
     

09 Oct, 2005

1 commit

  • dd0fc66fb   [PATCH] gfp flags annotations - part 1 ... Browse Code »

    - 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

    Al Viro
     

30 Aug, 2005

1 commit

  • 8728b834b   [NET]: Kill skb->list ... Browse Code »

    Remove the "list" member of struct sk_buff, as it is entirely
    redundant. All SKB list removal callers know which list the
    SKB is on, so storing this in sk_buff does nothing other than
    taking up some space.

    Two tricky bits were SCTP, which I took care of, and two ATM
    drivers which Francois Romieu fixed
    up.

    Signed-off-by: David S. Miller
    Signed-off-by: Francois Romieu

    David S. Miller
     

12 Jul, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »
    212

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds