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

On Tue, Jun 09, 2009 at 11:33:07PM +0200, Jille Timmermans wrote:
> 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.

Sometimes gdb just shows 0 instead of the correct value of a variable,
so do not trust too much that kern_open() did not report an error.

In the fstat output I saw that the problematic process had fd 0 open as
a pipe and fd 1 and 2 closed, and its parent was a cron(8) process. Now,
the cron_popen() function in usr.sbin/cron/cron/popen.c that cron uses
to mail things out opens _PATH_DEVNULL on fd 1 and 2 without checking if
it succeeds. So it is likely there was something wrong with /dev/null in
that jail.

> We also wondered why the kernel doesn't always have a devnull file
> descriptor ready, I guess it is usefull in more cases.

It is not used _that_ much, and I think the current approach has less
code complexity. Sharing the open file (like dup and sending file
descriptors over unix sockets) seems unwise because some state could be
shared across entirely unknowing processes (for example, fcntl with
F_SETFL will affect /dev/null open files to some degree even though it
returns an error code). Then, because /dev/null is very much like any
other device, the file descriptor would likely have to be hand-crafted
to a great extent.

-- 
Jilles Tjoelker