(audit?) Panic in 6.2-PRERELEASE

[Robert Watson]

On Fri, 5 Jan 2007, Ceri Davies wrote:

>> Much as I would love to trust the contents of ub there, I suspect they 
>> can't be trusted.  Could you print the contents of *fp in kern_fstat() in 
>> both of those stacks?  I'd particularly like to know the value of 
>> fp->f_type, and then depending on the type, possibly the contents of 
>> *(struct vnode *)fp->f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct socket 
>> *)fp->f_data in the case of DTYPE_SOCKET.
>
> Can you tell me how to get at *fp given that the stack trace shows fstat() 
> and not kern_fstat()?  Sorry if I'm being dumb but I don't know how to step 
> into the kern_fstat() call from fstat().

It could be that the stack is hosed losing the frame, or maybe it's inlined 
(more likely the former I think, as kern_fstat() is a symbol used elsewhere in 
the kernel).  The best bet may be to use the file descriptor number (uap->fd) 
to pull the struct file reference out of the process.  Something on the order 
of (td->td_proc->p_fd->fd_ofiles[fd]) should return the right struct file *.

How reproduceable is this?

Robert N M Watson
Computer Laboratory
University of Cambridge

>
>>> #7  0xc05cda7c in audit_arg_auditon () at /usr/src/sys/security/audit/audit_arg.c:586
>>> #8  0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at /usr/src/sys/kern/kern_descrip.c:1075
>
> Ceri
> -- 
> That must be wonderful!  I don't understand it at all.
>                                                  -- Moliere
>