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). 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. -- Jilles Tjoelker
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:49 UTC