linux-kernel - Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1178308173.3743.14.camel@amdx2.microgate.com>
Date:	Fri, 04 May 2007 14:49:33 -0500
From:	Paul Fulghum <paulkf@...rogate.com>
To:	Antonino Ingargiola <tritemio@...il.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-usb-users@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial
	possible bug]

On Fri, 2007-05-04 at 21:06 +0200, Antonino Ingargiola wrote:

> Filling with echo console-screen.sh I've found that the blocking command is:
> 
>     unicode_start 2> /dev/null || true
> 
> or at least the echo before this command is the last shown.

I still don't know what is blocking.

It is possible some tty device is operating with an improperly
initialized tty structure. I vaguely remember some console code
creating its own minimally initialized 'dummy' tty structure.

This might be causing the new flush code to hang.

Try this patch which does not call the flush unless a line
discipline is attached to the tty. That should indicate
a normally initialized tty structure.

--- a/drivers/char/tty_io.c	2007-04-25 22:08:32.000000000 -0500
+++ b/drivers/char/tty_io.c	2007-05-04 12:15:18.000000000 -0500
@@ -365,6 +365,28 @@ static void tty_buffer_free(struct tty_s
 }
 
 /**
+ *	tty_buffer_flush		-	flush full tty buffers
+ *	@tty: tty to flush
+ *
+ *	flush all the buffers containing receive data
+ *
+ *	Locking: none
+ */
+
+static void tty_buffer_flush(struct tty_struct *tty)
+{
+	struct tty_buffer *thead;
+	unsigned long flags;
+
+	spin_lock_irqsave(&tty->buf.lock, flags);
+	while((thead = tty->buf.head) != NULL) {
+		tty->buf.head = thead->next;
+		tty_buffer_free(tty, thead);
+	}
+	spin_unlock_irqrestore(&tty->buf.lock, flags);
+}
+
+/**
  *	tty_buffer_find		-	find a free tty buffer
  *	@tty: tty owning the buffer
  *	@size: characters wanted
@@ -1236,8 +1258,10 @@ void tty_ldisc_flush(struct tty_struct *
 {
 	struct tty_ldisc *ld = tty_ldisc_ref(tty);
 	if(ld) {
-		if(ld->flush_buffer)
+		if(ld->flush_buffer) {
 			ld->flush_buffer(tty);
+			tty_buffer_flush(tty);
+		}
 		tty_ldisc_deref(ld);
 	}
 }
@@ -3336,6 +3360,20 @@ int tty_ioctl(struct inode * inode, stru
 		case TIOCMBIC:
 		case TIOCMBIS:
 			return tty_tiocmset(tty, file, cmd, p);
+		case TCFLSH:
+			switch (arg) {
+			case TCIFLUSH:
+			case TCIOFLUSH:
+				/* flush tty buffer and allow ldisc to process ioctl */
+				ld = tty_ldisc_ref_wait(tty);
+				if (ld) {
+					if (ld->ioctl)
+						tty_buffer_flush(tty);
+					tty_ldisc_deref(ld);
+				}
+				break;
+			}
+			break;
 	}
 	if (tty->driver->ioctl) {
 		retval = (tty->driver->ioctl)(tty, file, cmd, arg);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/