Move a racy assertion in filt_pipewrite().

[markj]

Summary

Note that pipe_kqfilter() adds the knote to the list for the other end
of the pipe when initializing an EVFILT_WRITE knote. In particular,
the knote does not hold any kind of strong reference that prevents
pipeclose() from being called on the other end. pipeclose() removes
all knotes from that end's knlist, and after that happens,
kn_list_lock() is a no-op, so it's possible for filt_pipewrite() to be
called without the knlist lock held.

Move the assertion in filt_pipewrite() to handle this: we can safely
check for PIPE_EOF and pipe_present != PIPE_ACTIVE without the lock
since those are "sticky" states, i.e., PIPE_EOF is never cleared once it
is set, and pipe_state is only updated when the pipe is being closed.

Test Plan

Peter reported the panic caused by the failed assertion, and tested the patch.

[kib]

Why cannot the same happen for read side ?

[markj]

In D19224#411306, @kib wrote:

Why cannot the same happen for read side ?

pipe_kqfilter() does not handle EVFILT_READ and EVFILT_WRITE symmetrically. In the read case, the knote itself holds a reference on that end of the pipe, so pipeclose() will never be called.

[markj]

In D19224#411311, @markj wrote:

In D19224#411306, @kib wrote:

Why cannot the same happen for read side ?

pipe_kqfilter() does not handle EVFILT_READ and EVFILT_WRITE symmetrically. In the read case, the knote itself holds a reference on that end of the pipe, so pipeclose() will never be called.

I should say, pipeclose() will not be called before the knote is dropped.