On 1/10/2021 9:19 PM, Pavel Begunkov wrote:
The intended use case for buffer registration is:
- a group of processes attach a shmem segment
- one process registers the buffers in the shmem segment and shares it
- other processes attach that registration
For this case, it seems that there is really no need to wait for the attached processes to get rid of the their references since the shmem segment (and thus the registered buffers) will persist anyway until the last attached process goes away. So the last unregister could quiesce all references and get rid of the shared buf_data.
I'm not sure how useful the non-shmem use case would be anyway.
Would it makes sense to restrict the scope of this feature?
I have to say I like that generic resources thing, makes it easier to
extend in the future. e.g. pre-allocating dma mappings, structs like
bios, etc.
I didn't think it through properly but it also looks that with refnodes
it would be much easier to do sharing in the end, if not possible
vs impossible.
Do you think that an the unkillable deadlock is still an issue with your
changes in the v5 version of io_rsrc_ref_quiesce() I just sent out?
We're calling wait_for_completion_interruptible() so I assume it should
be interruptible. I think we'll then skip unmapping the buffers though,
so it's not clear to me what the right solution is for the below
scenario you raised in the first place:
task1: uring1 = create()
task2: uring2 = create()
task1: uring3 = create(share=uring2);
task2: uring4 = create(share=uring1);
task1: io_sqe_buffers_unregister(uring1)
task2: io_sqe_buffers_unregister(uring2)
