From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 4 20:40:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B7EE1065676 for ; Thu, 4 Feb 2010 20:40:36 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id E17FB8FC1D for ; Thu, 4 Feb 2010 20:40:35 +0000 (UTC) Received: from [172.31.193.10] (rrcs-98-101-145-84.midsouth.biz.rr.com [98.101.145.84]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id o14KeYnv019492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Feb 2010 15:40:35 -0500 (EST) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu o14KeYnv019492 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1265316035; bh=Btz2gXB0w1yjt3Z2+qilAIfJOUpHsbIT4NmtXCMYmUE=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=g/ncvKUd3jdOYjVv5irtZQQbnrtSdqAXxSBj6egONc17rw88qD1jhtzenVW8RLk15 COBM/U/7HmhKKUSoq07r1IqfgqOqUfr+Lqdjxl4Zqgqxxv5/Tj8vCfVxj51fB6EIHE ZBmgrhPgGG5xBaUDWyZAlKwhOZjByijPKLOMeVFs= Message-ID: <4B6B30BC.7030107@cs.duke.edu> Date: Thu, 04 Feb 2010 15:40:28 -0500 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: devfs panic w/INVARIANTS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 20:40:36 -0000 I've got a commercial driver that uses device cloning. At unload time, the driver calls clone_cleanup(). When I unload the driver when the kernel is built with INVARIANTS, I'll see a panic in devfs_populate_loop(). This happens in 6-stable, as well as 8-stable. From what I can see the clone has been freed, but it remains on the devfs cdevp_list. Then the next time devfs_populate_loop() is called, it trips over the bad entry (cdp->cdp_dirents points to 0xdeadc0dedeadc0de) See appended kgdb session. If I trace the code path, it looks like clone_cleanup() calls destroy_devl(). And destroy_devl() will eventually call devfs_free() if the si_refcnt is zero. But I don't see anything which will get the cdev removed from the cdevp_list prior to it being freed. The only code I see which will get the cdev removed from the cdevp_list() seems to be the "GC any lingering devices" block in devfs_populate_loop What am I missing? Thanks, Drew Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x8:0xffffffff803e8780 stack pointer = 0x10:0xffffffffade623b0 frame pointer = 0x10:0xffffffffade62400 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 896 (ps) Dumping 510 MB (2 chunks) Dumping 510 MB (2 chunks) Dumping 510 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 510MB (130528 pages) 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xffffffff801b8d91 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0x0) at ../../../ddb/db_command.c:493 #2 0xffffffff801b91e5 in db_command_loop () at ../../../ddb/db_command.c:408 #3 0xffffffff801bb0ed in db_trap (type=-1377427040, code=0) at ../../../ddb/db_main.c:222 #4 0xffffffff80468b99 in kdb_trap (type=9, code=0, tf=0xffffffffade62300) at ../../../kern/subr_kdb.c:473 #5 0xffffffff806c5d14 in trap_fatal (frame=0xffffffffade62300, eva=18446742974557577824) at ../../../amd64/amd64/trap.c:660 #6 0xffffffff806c62eb in trap (frame= {tf_rdi = -2136471632, tf_rsi = -2136471656, tf_rdx = -2401050962867404578, tf_rcx = 1, tf_r8 = -2136471624, tf_r9 = -1099151973792, tf_rax = 0, tf_rbx = -1099307447040, tf_rbp = -1377426432, tf_r10 = 0, tf_r11 = 4, tf_r12 = 0, tf_r13 = -1099086652928, tf_r14 = -1099307447040, tf_r15 = 86032452, tf_trapno = 9, tf_addr = 0, tf_flags = -2143029088, tf_err = 0, tf_rip = -2143385728, tf_cs = 8, tf_rflags = 66071, tf_rsp = -1377426496, tf_ss = 16}) at ../../../amd64/amd64/trap.c:470 #7 0xffffffff806ad84b in calltrap () at ../../../amd64/amd64/exception.S:168 #8 0xffffffff803e8780 in devfs_populate_loop (dm=0xffffff000c2b8d00, cleanup=0) at ../../../fs/devfs/devfs_devs.c:370 #9 0xffffffff803e8beb in devfs_populate (dm=0xffffff000c2b8d00) at ../../../fs/devfs/devfs_devs.c:486 #10 0xffffffff803eafab in devfs_lookup (ap=0x0) at ../../../fs/devfs/devfs_vnops.c:587 #11 0xffffffff80724a2e in VOP_LOOKUP_APV (vop=0xffffffff80948600, a=0xffffffffade62630) at vnode_if.c:99 #12 0xffffffff804aadb2 in lookup (ndp=0xffffffffade629c0) at vnode_if.h:56 #13 0xffffffff804abb66 in namei (ndp=0xffffffffade629c0) at ../../../kern/vfs_lookup.c:216 #14 0xffffffff804c1be2 in vn_open_cred (ndp=0xffffffffade629c0, flagp=0xffffffffade6290c, cmode=0, cred=0xffffff000009ac00, fdidx=3) at ../../../kern/vfs_vnops.c:183 #15 0xffffffff804b8d64 in kern_open (td=0xffffff00156fe260, path=0xffffffff mode=373490024) at ../../../kern/vfs_syscalls.c:1016 #16 0xffffffff804b9455 in open (td=0xffffffff80a807b0, uap=0xffffffffade62bc0) at ../../../kern/vfs_syscalls.c:971 #17 0xffffffff806c6b52 in syscall (frame= {tf_rdi = 4218321, tf_rsi = 0, tf_rdx = 0, tf_rcx = 0, tf_r8 = 140737488348272, tf_r9 = 0, tf_rax = 5, tf_rbx = 5300224, tf_rbp = 4218321, tf_r10 = 0, tf_r11 = 5300224, tf_r12 = 4218321, tf_r13 = 0, tf_r14 = 140737488348272, tf_r15 = 6, tf_trapno = 12, tf_addr = 5300224, tf_flags = 0, tf_err = 2, tf_rip = 34369309420, tf_cs = 43, tf_rflags = 514, tf_rsp = 140737488347528, tf_ss = 35}) at ../../../amd64/amd64/trap.c:807 #18 0xffffffff806ada48 in Xfast_syscall () at ../../../amd64/amd64/exception.S:287 #19 0x0000000800920aec in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 7 #7 0xffffffff806ad84b in calltrap () at ../../../amd64/amd64/exception.S:168 168 call trap Current language: auto; currently asm (kgdb) up #8 0xffffffff803e8780 in devfs_populate_loop (dm=0xffffff000c2b8d00, cleanup=0) at ../../../fs/devfs/devfs_devs.c:370 370 if ((cleanup || !(cdp->cdp_flags & CDP_ACTIVE)) && Current language: auto; currently c (kgdb) p cdp $1 = (struct cdev_priv *) 0xffffff0019549a00 (kgdb) p *cdp $2 = {cdp_c = {si_priv = 0xdeadc0dedeadc0de, si_flags = 3735929054, si_atime = {tv_sec = -2401050962867404578, tv_nsec = -2401050962867404578}, si_ctime = {tv_sec = -2401050962867404578, tv_nsec = -2401050962867404578}, si_mtime = {tv_sec = -2401050962867404578, tv_nsec = -2401050962867404578}, si_uid = 3735929054, si_gid = 3735929054, si_mode = 49374, si_cred = 0xdeadc0dedeadc0de, si_drv0 = 3735929054, si_refcount = -559038242, si_list = { le_next = 0xdeadc0dedeadc0de, le_prev = 0xdeadc0dedeadc0de}, si_clone = {le_next = 0xdeadc0dedeadc0de, le_prev = 0xdeadc0dedeadc0de}, si_children = {lh_first = 0xdeadc0dedeadc0de}, si_siblings = { le_next = 0xdeadc0dedeadc0de, le_prev = 0xdeadc0dedeadc0de}, si_parent = 0xdeadc0dedeadc0de, si_name = 0xdeadc0dedeadc0de
, si_drv1 = 0xdeadc0dedeadc0de, si_drv2 = 0xdeadc0dedeadc0de, si_devsw = 0xdeadc0dedeadc0de, si_iosize_max = -559038242, ade629c0 "Ñ]@", pathseg=343718984, flags=1,