Re: panic: oof, we didn't get our fd while playing with devfs(8) and jails

Jilles Tjoelker schreef:
> On Mon, Jun 08, 2009 at 09:12:54PM +0200, Jille Timmermans wrote:
>> I was playing with the new hierarchical jails (yay!) and devfs(8) to
>> tune the devfs mountpoints. At some point I tried to apply another
>> ruleset and the machine panic'd a few seconds later.
>> I haven't been able to reproduce this.
> 
>> [panic: oof, we didn't get our fd from fdcheckstd() in kern_exec.c]
> 
> This KASSERT may happen if you execute a setuid/setgid program with one
> or more of fd 0, 1, 2 closed, and you cannot open /dev/null (e.g. not
> present, bad permissions). The assertion checks td->td_retval[0] even if
> kern_open() failed. After that, if td->td_retval[0] happened to be equal
> to the expected value or INVARIANTS was disabled, the function checks if
> kern_open() failed. If so, it returns an error which eventually causes
> "whoops, no process anymore" process termination in do_execve() (appears
> as SIGABRT).
I'm sorry, I forgot to tell that error = 0. (and INVARIANTS is enabled)

(kgdb) frame 3
#3  0xc0609399 in fdcheckstd (td=0xc41bfd80)
    at /usr/src/sys/kern/kern_descrip.c:1946
1946                            KASSERT(devnull == i, ("oof, we didn't
get our fd"));
(kgdb) print error
$1 = 0

might this have anything to do with the lockless file descriptor lookup
? (Cc'ing jeff_at_)

I have reproduced the panic a second time; but haven't figured out why
it didn't panic my third time.

I talked about this with ed_at_ on IRC; but after that my best guess was
that kern_open() was mistaking. We also wondered why the kernel doesn't
always have a devnull file descriptor ready, I guess it is usefull in
more cases.

-- Jille
> 
> Moving the assertion below the error check seems to fix the problem (see
> attached patch).
> 
> It may also be helpful to KASSERT or comment that
> thread_single(SINGLE_BOUNDARY) or similar must be in effect, otherwise
> our work could be undone by other threads (similar to the
> KASSERT(fdp->fd_refcnt == 1) already present). kern_exec.c takes care of
> both of these.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"