- fix-for-the-pptp-hangs-that-have-been-reported.patch removed from -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The patch titled

     Fix for the PPTP hangs that have been reported

has been removed from the -mm tree.  Its filename is

     fix-for-the-pptp-hangs-that-have-been-reported.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
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

macintosh-mangle-caps-lock-events-on-adb-keyboards.patch
ppp_async-hang-fix.patch
git-powerpc.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

[Index of Archives]     [Kernel Newbies FAQ]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux