On 11/19/2020 9:35 AM, Pavel Begunkov wrote:
On 19/11/2020 02:34, Bijan Mottahedeh wrote:
Ok, there are 2 new patches in 5.10, you may wait for Jens to propagate it to
5.11 or just cherry-pick (no conflicts expected) them. On top apply ("io_uring:
share fixed_file_refs b/w multiple rsrcs") to which I CC'ed you. It's
simple enough so shouldn't be much problems with it.
With that you need to call io_set_resource_node() every time you take
a resource. That's it, _no_ extra ref_put for you to add in puts/free/etc.
Thanks for the patches.
Also, consider that all ref_nodes of all types should be hooked into a
single ->ref_list (e.g. file_data->ref_list).
Just so I understand, would this common ref_list create any dependency between resource types when unregistering a given resource type?
For example in
io_sqe_files_unregister()
{
...
if (ref_node)
percpu_ref_kill(&ref_node->refs);
percpu_ref_kill(&data->refs);
...
}
with the "order refnode recycling" patch, would files_unregister block until all requests using either fixed files or fixed buffers complete?
Yes, IORING_UNREGISTER_FILES will block even if there is a fixed
buffer request, but IORING_REGISTER_FILES_UPDATE would not.
The latter follows RCU idea, it removes resources without blocking
a syscall, so these resources are not accessible for new requests,
but actual close(file), etc. happens sometime later after all previous
requests with fixed resources (of any kind) complete.
IORING_OP_FILES_UPDATE works similarly but I need to look it up
to be sure.
Does it answer you question?
I think so, we want to treat fixed resources as uniformly as possible.
The fact that the unregister dependency is intentional might not be
immediately obvious so some comments would be needed.
