The patch titled
Fix for the PPTP hangs that have been reported
has been added to the -mm tree. Its filename is
fix-for-the-pptp-hangs-that-have-been-reported.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: Fix for the PPTP hangs that have been reported
From: Paul Mackerras <paulus@xxxxxxxxx>
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: Paul Mackerras <paulus@xxxxxxxxx>
Cc: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Cc: Paul Fulghum <paulkf@xxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
drivers/char/n_tty.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN drivers/char/n_tty.c~fix-for-the-pptp-hangs-that-have-been-reported drivers/char/n_tty.c
--- devel/drivers/char/n_tty.c~fix-for-the-pptp-hangs-that-have-been-reported 2006-06-11 20:50:15.000000000 -0700
+++ devel-akpm/drivers/char/n_tty.c 2006-06-11 20:50:15.000000000 -0700
@@ -1384,8 +1384,10 @@ do_it_again:
* longer than TTY_THRESHOLD_UNTHROTTLE in canonical mode,
* we won't get any more characters.
*/
- if (n_tty_chars_in_buffer(tty) <= TTY_THRESHOLD_UNTHROTTLE)
+ if (n_tty_chars_in_buffer(tty) <= TTY_THRESHOLD_UNTHROTTLE) {
+ n_tty_set_room(tty);
check_unthrottle(tty);
+ }
if (b - buf >= minimum)
break;
_
Patches currently in -mm which might be from paulus@xxxxxxxxx are
powerpc-console_initcall-ordering-issues.patch
fix-for-the-pptp-hangs-that-have-been-reported.patch
macintosh-mangle-caps-lock-events-on-adb-keyboards.patch
ppp_async-hang-fix.patch
git-powerpc.patch
git-powerpc-fix.patch
work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch
add-poisonh-and-patch-primary-users.patch
x86-powerpc-make-hardirq_ctx-and-softirq_ctx-__read_mostly.patch
define-__raw_get_cpu_var-and-use-it.patch
apple-motion-sensor-driver.patch
fix-broken-dubious-driver-suspend-methods.patch
drivers-use-list_move.patch
lock-validator-add-per_cpu_offset-fix.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
