[Question] 9p/virtio: zero-copy pages after interrupted request

[Yuho Choi <oss.patchbox@gmail.com>]

Hi,

I have a question about the zero-copy page lifetime in
p9_virtio_zc_request() (mainline 067c5c24cef2) and would appreciate your
view.

After virtqueue_add_sgs() and virtqueue_kick(), the function waits for the
response with io_wait_event_killable().  If a signal interrupts that wait,
it reaches err_out and calls p9_release_pages() before returning
-ERESTARTSYS.  Only after the transport returns does p9_client_zc_rpc()
send TFLUSH.

If I read this correctly, the sequence can be:

  publish the zero-copy scatterlist to the virtqueue
  interrupt the wait with a signal
  drop the user page references
  send TFLUSH
  finish or cancel the original backend request

The virtio backend still owns the original descriptor when the page
references are dropped, so it seems able to access pages that can meanwhile
be unmapped and reused.

I also checked QEMU's 9p backend (71f25c75417d).  v9fs_flush() marks
the original PDU cancelled and waits on cancel_pdu->complete.
pdu_complete() calls push_and_notify() for the original PDU before
waking that waiter, and the flush coroutine then completes RFLUSH.  A
successfully cancelled PDU is returned with a zero used length.  This
ordering suggests that the original request can remain active after
Linux has released the pages.

Is there a 9p or virtio guarantee I am missing that makes it safe to
release the pages as soon as the killable wait returns?  Or should the
pages and the transport's request reference remain alive until
req_done() consumes the original used buffer, including a zero-length
completion after TFLUSH?

Thanks,
Yuho