Seems that tty->read_buf == NULL at the very beginning of n_tty_read():
1723 do_it_again:
1724
1725 BUG_ON(!tty->read_buf);
tty->read_buf access needs tty->read_lock to be held, correct? So
perhaps the patch would be:
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index ee1c268..9decb1c 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1728,7 +1728,11 @@ static ssize_t n_tty_read(struct tty_struct *tty,
struct file *file,
do_it_again:
+#ifdef CONFIG_BUG
+ spin_lock_irqsave(&tty->read_lock, flags);
BUG_ON(!tty->read_buf);
+ spin_unlock_irqrestore(&tty->read_lock, flags);
+#endif
c = job_control(tty, file);
if (c < 0)
Regards,
-Stanislav Kozina
On Wed, 25 Jul 2012 09:47:09 +0800
"大林"<yourdarling1999@xxxxxxxx> wrote:
Hello.
Here's a kernel panic caused by n_tty_read, linux kernel version is 2.6.38.8.
There are many discussions on the subject, this bug solved yet? Where can I download the patch?
Thats a different trace to the others I've seen. Several races have been
fixed, there are certainly a couple of others left to sort eventually. I
don't believe anyone is currently working on them (and indeed until the
rest of the locking and lock splitting work is done it's difficult to see
how any useful progress could be made here). Patches are however welcome.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
