Skip to content

L
linux-davinci-2.6.23
Switch branch/tag
  1. 12 Jun, 2006 4 commits
    • Weidong's avatar
      [IPV4]: Increment ipInHdrErrors when TTL expires. · 42d1d52e
      Weidong authored 
      Signed-off-by: default avatarWeidong <weid@nanjing-fnst.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      42d1d52e
    • Aki M Nyrhinen's avatar
      [TCP]: continued: reno sacked_out count fix · 79320d7e
      Aki M Nyrhinen authored 
      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: default avatarDavid S. Miller <davem@davemloft.net>
      79320d7e
    • Andrea Bittau's avatar
      [DCCP] Ackvec: fix soft lockup in ackvec handling code · afec35e3
      Andrea Bittau authored 
      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: default avatarAndrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: default avatarIan McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      afec35e3
    • Paul Mackerras's avatar
      [PATCH] Fix for the PPTP hangs that have been reported · 289a1e99
      Paul Mackerras authored 
      People have been reporting that PPP connections over ptys, such as
used with PPTP, will hang randomly when transferring large amounts of
data, for instance in http://bugzilla.kernel.org/show_bug.cgi?id=6530.
I have managed to reproduce the problem, and the patch below fixes the
actual cause.

The problem is not in fact in ppp_async.c but in n_tty.c.  What
happens is that when pptp reads from the pty, we call read_chan() in
drivers/char/n_tty.c on the master side of the pty.  That copies all
the characters out of its buffer to userspace and then calls
check_unthrottle(), which calls the pty unthrottle routine, which
calls tty_wakeup on the slave side, which calls ppp_asynctty_wakeup,
which calls tasklet_schedule.  So far so good.  Since we are in
process context, the tasklet runs immediately and calls
ppp_async_process(), which calls ppp_async_push, which calls the
tty->driver->write function to send some more output.

However, tty->driver->write() returns zero, because the master
tty->receive_room is still zero.  We haven't returned from
check_unthrottle() yet, and read_chan() only updates tty->receive_room
_after_ calling check_unthrottle.  That means that the driver->write
call in ppp_async_process() returns 0.  That would be fine if we were
going to get a subsequent wakeup call, but we aren't (we just had it,
and the buffer is now empty).

The solution is for n_tty.c to update tty->receive_room _before_
calling the driver unthrottle routine.  The patch below does this.
With this patch I was able to transfer a 900MB file over a PPTP
connection (taking about 25 minutes), whereas without the patch the
connection would always stall in under a minute.
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      289a1e99
  3. 11 Jun, 2006 8 commits
  5. 10 Jun, 2006 8 commits
  7. 09 Jun, 2006 5 commits
  9. 08 Jun, 2006 13 commits
  11. 06 Jun, 2006 1 commit
  13. 05 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 · ff3ea47c
      Linus Torvalds authored 
      * master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [BRIDGE]: fix locking and memory leak in br_add_bridge
  [IRDA]: Missing allocation result check in irlap_change_speed().
  [PPPOE]: Missing result check in __pppoe_xmit().
  [NET]: Eliminate unused /proc/sys/net/ethernet
  [NETCONSOLE]: Clean up initcall warning.
  [TCP]: Avoid skb_pull if possible when trimming head
      ff3ea47c