Date: Fri, 29 Feb 2008 10:10:50 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: freebsd-usb@freebsd.org Subject: Re: ucom: orphaned ttyUX ? Message-ID: <47C7BE0A.5050600@icyb.net.ua> In-Reply-To: <47C7294B.6020306@icyb.net.ua> References: <47C7294B.6020306@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47C7BE0A.5050600>