Date: Sun, 22 Jun 2003 14:31:10 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: tjr@FreeBSD.org Cc: src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/tools vnode_if.awk Message-ID: <200306222131.h5MLVAM7067545@gw.catspoiler.org> In-Reply-To: <200306221905.h5MJ5aM7067354@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 Jun, I wrote: > On 22 Jun, Tim Robbins wrote: >> On Fri, Jun 20, 2003 at 05:15:37AM -0700, Stefan Esser wrote: >> >>> se 2003/06/20 05:15:37 PDT >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/tools vnode_if.awk >>> Log: >>> The assertions generated to test VFS locking never included checks >>> for vnodes reached through double indirection (i.e. **vpp). This >>> is worked-around by special-casing the identifier "vpp" (adding one >>> level of indirection). >> >> Since this commit, I've been getting a kernel panic when the kernel tries >> to start init. Reverting vnode_if.awk to the previous revision makes the >> problem go away. >> >> kernel: type 12 trap, code=0 >> Stopped at assert_vi_unlocked+0x12: movl 0x1c(%ecx),%eax >> db> tr >> assert_vi_unlocked(0, ...) at assert_vi_unlocked+0x12 >> VOP_CACHEDLOOKUP(...) >> vfs_cache_lookup(...) >> ufs_vnoperate(...) >> lookup(...) >> namei(...) >> kern_mkdir(...) >> start_init(...) >> fork_exit(...) >> fork_trampoline() > > Same here. This change exposed a pre-existing bug in the handling of > the '-' flag in the specification. I fixed that in my local tree and > got a bit further: > > Mounting root from ufs:/dev/da0s1a > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x471bd42d > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc64207ff > stack pointer = 0x10:0xdf0406b7 > frame pointer = 0x10:0xdf0406e4 > 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 = 1 (swapper) > kernel: type 12 trap, code=0 > Stopped at 0xc64207ff: rolb $0x4d,0x86c0524d(%esi) > db> tr > _end(c64207fc,1b,0,0,df04073c) at 0xc64207ff > vnode_pager_haspage(c07a8378,6c,0,df040798,df040794) at vnode_pager_haspage+0x1a > e > vm_fault_additional_pages(c08cff80,0,0,df04086c,df04081c) at vm_fault_additional > _pages+0xbb > vm_fault(c07a2000,dc370000,1,0,c2123720) at vm_fault+0x83a > trap_pfault(df040948,0,dc370000,c0315455,dc370000) at trap_pfault+0x181 > trap(18,10,10,80b5000,dc370000) at trap+0x3cd > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc04b51dc, esp = 0xdf040988, ebp = 0xdf0409e0 --- > slow_copyout(c2122d3c,c2131000,c64207fc,c07a8378,6b4a0) at slow_copyout+0x4 > exec_elf32_imgact(df040b3c,df040b50,c051b3d3,105,c0318370) at exec_elf32_imgact+ > 0x2a5 > kern_execve(c2123720,bfbffff2,bfbfffe4,0,0) at kern_execve+0x36c > execve(c2123720,df040cf0,0,0,df040cd8) at execve+0x30 > start_init(0,df040d48,c051b546,312,0) at start_init+0x42e > fork_exit(c02fbea0,0,df040d48) at fork_exit+0xc0 > fork_trampoline() at fork_trampoline+0x1a > --- trap 0x1, eip = 0, esp = 0xdf040d7c, ebp = 0 --- > > > I don't know why the vnode_if.awk change would cause this, so I backed > out the change to very that this panic isn't caused by something else I > picked up in my last cvsup. I tracked this down to the added checks on *vpp in the VOP_BMAP() wrapper. It appears to be legal to pass a NULL pointer as the vpp argument to VOP_BMAP(), which I would have expected to have gotten dereferenced by the new assertion checking code in the VOP_BMAP() wrapper. The stack trace above doesn't make any sense to me, but skipping the assertion check if vpp is NULL allows the machine to boot. I checked in a change to vnode_if.awk that fixes this problem as well as the first problem. The first problem was caused by checking the state of the vnode interlock even when the specification says that the vnode locks should not be checked. It could be triggered if the caller passed a value in vpp that pointed to NULL pointer (so that the VOP call could return the actual vnode pointer in that location) or if the VOP call cleared the location pointed to by vpp, possibly because the VOP call encountered an error.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306222131.h5MLVAM7067545>