cvs commit: src/sys/tools vnode_if.awk

[Don Lewis]

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.