relative openat dirfd reference on submit

Vito Caputo
2020-11-02T21:00:48Z

Hello list,

I've been tinkering a bit with some async continuation passing style
IO-oriented code employing liburing. This exposed a kind of awkward
behavior I suspect could be better from an ergonomics perspective.

Imagine a bunch of OPENAT SQEs have been prepared, and they're all
relative to a common dirfd. Once io_uring_submit() has consumed all
these SQEs across the syscall boundary, logically it seems the dirfd
should be safe to close, since these dirfd-dependent operations have
all been submitted to the kernel.

But when I attempted this, the subsequent OPENAT CQE results were all
-EBADFD errors. It appeared the submit didn't add any references to
the dependent dirfd.

To work around this, I resorted to stowing the dirfd and maintaining a
shared refcount in the closures associated with these SQEs and
executed on their CQEs. This effectively forced replicating the
batched relationship implicit in the shared parent dirfd, where I
otherwise had zero need to. Just so I could defer closing the dirfd
until once all these closures had run on their respective CQE arrivals
and the refcount for the batch had reached zero.

It doesn't seem right. If I ensure sufficient queue depth and
explicitly flush all the dependent SQEs beforehand
w/io_uring_submit(), it seems like I should be able to immediately
close(dirfd) and have the close be automagically deferred until the
last dependent CQE removes its reference from the kernel side.

Regards,
Vito Caputo