ucom: orphaned ttyUX ?

[Andriy Gapon]

on 28/02/2008 23:36 Andriy Gapon said the following:
> I recently had a bad experience with ucom. I didn't try to reproduce it
> in a controlled way, so that I could fully document it. So, here's my
> recollection and impression/understanding of it with couple of facts on top.
> 
> The bad experience: system crash with the following info:
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x4
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc4611c2b
> stack pointer           = 0x28:0xd1d3395c
> frame pointer           = 0x28:0xd1d33974
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 8979 (pppd)
> trap number             = 12
> panic: page fault
> KDB: stack backtrace:
> db_trace_self_wrapper(c06b76ef,d1d337fc,c04f577a,c06b4e67,c0d9f6e0,...)
> at 0xc0437e56 = db_trace_self_wrapper+0x26
> kdb_backtrace(c06b4e67,c0d9f6e0,c06a7d40,d1d33808,d1d33808,...) at
> 0xc051ad69 = kdb_backtrace+0x29
> panic(c06a7d40,c06cf0ab,c4219cd4,1,1,...) at 0xc04f577a = panic+0xaa
> trap_fatal(c4219b40,0,c06ceeff,31b,4,...) at 0xc067e5d3 = trap_fatal+0x353
> trap_pfault(c06bc33a,d1d338c4,c04e9fc9,8,c,...) at 0xc067e7bb =
> trap_pfault+0x1db
> trap(d1d3391c) at 0xc067f182 = trap+0x3c2
> calltrap() at 0xc066e2db = calltrap+0x6
> --- trap 0xc, eip = 0xc4611c2b, esp = 0xd1d3395c, ebp = 0xd1d33974 ---
> ucommodem(c28f6400,3,0,c06b41c5,0,...) at 0xc4611c2b = ucommodem+0xab
> ttyopen(c345ed00,7,2000,c3468a50,c06ee960,...) at 0xc0535b10 = ttyopen+0x180
> giant_open(c345ed00,7,2000,c3468a50,7,...) at 0xc04ca70f = giant_open+0x4f
> devfs_open(d1d33a70,c06d1f98,1e2,c06d267e,c3a1caa0,...) at 0xc04968c8 =
> devfs_open+0x1d8
> VOP_OPEN_APV(c06dfee0,d1d33a70,8eb,c0558155,c3a1caa0,...) at 0xc0696062
> = VOP_OPEN_APV+0x42
> vn_open_cred(d1d33b64,d1d33c5c,0,c33c8800,c3823900,...) at 0xc0570b2d =
> vn_open_cred+0x45d
> vn_open(d1d33b64,d1d33c5c,0,c3823900,8,...) at 0xc0570c33 = vn_open+0x33
> kern_open(c3468a50,8063280,0,7,0,...) at 0xc056f873 = kern_open+0xf3
> open(c3468a50,d1d33cfc,3fe,c06cef20,c3468a50,...) at 0xc056fd70 = open+0x30
> syscall(d1d33d38) at 0xc067eb03 = syscall+0x323
> Xint0x80_syscall() at 0xc066e340 = Xint0x80_syscall+0x20
> --- syscall (5, FreeBSD ELF32, open), eip = 0x283123fb, esp =
> 0xbfbfe71c, ebp = 0xbfbfe7f8 ---
> 
> Apparently, this is a "null pointer dereferencing" crash. (tried to
> dereference a field of structure pointed to with NULL).
> What happened before:
> connected a device recognized by ucom, /dev/ttyU0 appeared
> disconnected the device, ucom noticed that, but ttyU0 did not disappear
> re-connected the device
> (I believe that this time ttyU1 was created for it, but I haven't checked)
> by mistake used ttyU0 again
> got the crash

Well, it wasn't ttyU1, it was ttyU0:
$ ls -l /dev/ttyU0
crw-------  1 root  wheel    0, 132 28 Feb 22:37 /dev/ttyU0
$ ls -l /dev/ttyU0*
crw-------  1 root  wheel    0, 132 28 Feb 22:37 /dev/ttyU0
crw-------  1 root  wheel    0, 132 28 Feb 22:37 /dev/ttyU0
crw-------  1 root  wheel    0, 132 28 Feb 22:37 /dev/ttyU0
crw-------  1 root  wheel    0, 132 28 Feb 22:37 /dev/ttyU0
crw-------  1 root  wheel    0, 133 28 Feb 12:33 /dev/ttyU0.init
crw-------  1 root  wheel    0, 133 28 Feb 12:33 /dev/ttyU0.init
crw-------  1 root  wheel    0, 133 28 Feb 12:33 /dev/ttyU0.init
crw-------  1 root  wheel    0, 133 28 Feb 12:33 /dev/ttyU0.init
crw-------  1 root  wheel    0, 134 28 Feb 12:33 /dev/ttyU0.lock
crw-------  1 root  wheel    0, 134 28 Feb 12:33 /dev/ttyU0.lock
crw-------  1 root  wheel    0, 134 28 Feb 12:33 /dev/ttyU0.lock
crw-------  1 root  wheel    0, 134 28 Feb 12:33 /dev/ttyU0.lock

So there are multiple ttyU0, and I guess that only one of them is
"good". So opening ttyU0 is almost like playing russian roulette.

> I believe that this is another example of a bad use of our device
> cloning, but I can be very wrong here.
> 


-- 
Andriy Gapon