Alan,
My apologizes for really late response, I completely missed your email:-/
We had few customers who met panics in n_tty_read() with following
backtrace:
#8 [ffff880018b8dcd0] page_fault at ffffffff814ddfe5
[exception RIP: n_tty_read+0x2c9]
<register output removed>
#9 [ffff880018b8dea0] tty_read at ffffffff81300b16
#10 [ffff880018b8def0] vfs_read at ffffffff81172f85
#11 [ffff880018b8df30] sys_read at ffffffff811730c1
#12 [ffff880018b8df80] system_call_fastpath at ffffffff8100b172
What serial driver are they using when they hit this ?
From kernel log:
kernel: Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
kernel: 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
kernel: 00:0a: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
My patch for this panic is attached (tty_panic.patch), in short - I
believe that we need to hold&tty->read_lock while checking
tty->read_cnt in while-loop condition in n_tty_read() here:
We can't hold the lock for the loop because we touch user space memory.
You mean call to tty_put_user(), correct? Thanks for this catch.
So what about to unlock the lock for this time? Because we need to hold
the lock while checking tty->read_cnt in the while loop condition, correct?
Thanks and regards,
-Stanislav Kozina
--
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
