1. 18 6月, 2006 22 次提交
  2. 15 6月, 2006 1 次提交
  3. 14 6月, 2006 6 次提交
  4. 13 6月, 2006 8 次提交
  5. 12 6月, 2006 3 次提交
    • L
      Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev · 0e838b72
      Linus Torvalds 提交于
      * 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev:
        [PATCH] sata_mv: grab host lock inside eng_timeout
      0e838b72
    • A
      [TCP]: continued: reno sacked_out count fix · 79320d7e
      Aki M Nyrhinen 提交于
      From: Aki M Nyrhinen <anyrhine@cs.helsinki.fi>
      
      IMHO the current fix to the problem (in_flight underflow in reno)
      is incorrect.  it treats the symptons but ignores the problem. the
      problem is timing out packets other than the head packet when we
      don't have sack. i try to explain (sorry if explaining the obvious).
      
      with sack, scanning the retransmit queue for timed out packets is
      fine because we know which packets in our retransmit queue have been
      acked by the receiver.
      
      without sack, we know only how many packets in our retransmit queue the
      receiver has acknowledged, but no idea which packets.
      
      think of a "typical" slow-start overshoot case, where for example
      every third packet in a window get lost because a router buffer gets
      full.
      
      with sack, we check for timeouts on those every third packet (as the
      rest have been sacked). the packet counting works out and if there
      is no reordering, we'll retransmit exactly the packets that were 
      lost.
      
      without sack, however, we check for timeout on every packet and end up
      retransmitting consecutive packets in the retransmit queue. in our
      slow-start example, 2/3 of those retransmissions are unnecessary. these
      unnecessary retransmissions eat the congestion window and evetually
      prevent fast recovery from continuing, if enough packets were lost.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      79320d7e
    • A
      [DCCP] Ackvec: fix soft lockup in ackvec handling code · afec35e3
      Andrea Bittau 提交于
      A soft lockup existed in the handling of ack vector records.
      Specifically, when a tail of the list of ack vector records was
      removed, it was possible to end up iterating infinitely on an element
      of the tail.
      Signed-off-by: NAndrea Bittau <a.bittau@cs.ucl.ac.uk>
      Signed-off-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      afec35e3