panic: oof, we didn't get our fd while playing with devfs(8)
jille at quis.cx
Tue Jun 9 21:33:13 UTC 2009
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 even if
> kern_open() failed. After that, if td->td_retval 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)
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@)
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@ 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
> 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
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current