Avoid creating unkillable processes with sendfile(SF_SYNC).

[markj]

Summary

The SF_SYNC flag causes sendfile(2) to "sleep until the network stack no
longer references the VM pages of the file." This is implemented using
a struct sendfile_sync which is referenced by each mbuf cluster
containing file data, and sendfile(2) sleeps uninterruptibly until all
references are gone.

Suppose a single-threaded process uses sendfile(SF_SYNC) to transmit a
file over a unix socket pair that is private to the process (e.g.,
created with socketpair(2)). Then sendfile() will block until the data
is read from the receiving socket buffer, but this cannot happen unless
the socket is closed, so the process is unkillable.

Fix the problem by making the sendfile(2) wait interruptible. When the
wait is interrupted, sendfile's mbuf destructor callbacks are
responsible for freeing the structure. Make the implementation a bit
lighter by using a refcount (for sendfile_sync structure refs) and a
blockcount (to wait for mbuf references to decrement to zero), instead
of a mutex and condition variable.

Extend blockcount to support interruptible sleeps.

Test Plan

Reported and tested by pho.

[kib]

sys/kern/kern_sendfile.c

1204

You will need blockcount merged to stable/12, or use cv_wait_sig() there. I think it is an argument to do it with _sig() one-liner first, and then commit this patch over.

sys/kern/kern_synch.c

408

In fact it is EINTR or ERESTART.

[markj]

_blockcount_sleep() can return ERESTART.

[markj]

sys/kern/kern_sendfile.c

1204

It is not sufficient to just convert to cv_wait_sig(): we will end up leaking the sendfile_sync structure if the wait is interrupted. I will commit the blockcount changes first, then prepare a patch that does not use blockcount, so it can be merged to stable/12.