mkl Note: PPPoE client connected to server, can ping, but cannot iperf

2010年3月25日星期四

PPPoE client connected to server, can ping, but cannot iperf

Linux-2.6.31.1
Running PPPoE client to server, ping is ok, but iperf-ing failed.

After some debug, found that the kernel loop in the for loop of ppp_async_push endlessly

__qdisc_run
qdisc_restart
dev_hard_start_xmit
ppp_start_xmit
ppp_xmit_process
ppp_push
ppp_async_send
ppp_async_push

pty_write

flush_to_ldisc

ChangeLog-2.6.31.2
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.31.2

commit a7207f0d215647ce7ee5f0e6308d6afab6f3584c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri Sep 18 07:05:58 2009 -0700

pty_write: don't do a tty_wakeup() when the buffers are full

commit 202c4675c55ddf6b443c7e057d2dff6b42ef71aa upstream.

Commit ac89a9174 ("pty: don't limit the writes to 'pty_space()' inside
'pty_write()'") removed the pty_space() checking, in order to let the
regular tty buffer code limit the buffering itself.

That was all good, but as a subtle side effect it meant that we'd be
doing a tty_wakeup() even in the case where the buffers were all filled
up, and didn't actually make any progress on the write.

Which sounds innocuous, but it interacts very badly with the ppp_async
code, which has an infinite loop in ppp_async_push() that tries to push
out data to the tty. When we call tty_wakeup(), that loop ends up
thinking that progress was made (see the subtle interactions between
XMIT_WAKEUP and 'tty_stuffed' for details). End result: one unhappy ppp
user.

Fixed by noticing when tty_insert_flip_string() didn't actually do
anything, and then not doing any more processing (including, very much
not calling tty_wakeup()).

Bisected-and-tested-by: Peter Volkov <pva@gentoo.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>