Cancellation safety

[Nugine]

Worker::tag_recv accepts &mut [MaybeUninit<u8>] as a data buffer.

async-ucx/src/ucp/endpoint/tag.rs

Lines 5 to 8 in d382387

	pub async fn tag_recv(&self, tag: u64, buf: &mut [MaybeUninit<u8>]) -> usize {
	let (_, len) = self.tag_recv_mask(tag, u64::max_value(), buf).await;
	len
	}

However, a future can be cancelled(dropped) at any time. While the IO operation is still in progress, the data buffer may be used after free. It's an unsoundness issue.

[wangrunji0408]

Yes, this issue needs to be fixed in the future.

One possible way is to call ucp_request_cancel in the drop function.

[Nugine]

The data buffer is invalid once the drop function is called.
Any IO operation should stop using the buffer immediatiley.
Does ucp_request_cancel have such an effect?

[wangrunji0408]

I think it does. But I can't find proof in the UCX docs.

[Nugine]

This line requires a mutable exclusive access. But the completion callback may be called in another thread at any time.
Is there any guarantee for the &mut Request?

async-ucx/src/ucp/endpoint/mod.rs

Line 131 in d382387

let request = unsafe { &mut *(self.ptr as *mut Request) };

[wangrunji0408]

Oh in fact an immutable reference is enough, because the AtomicWaker guarantees thread safety.

And it is also safe to get mutable reference here (but don't pass it out). Because both Worker and Endpoint are !Send, IO functions and their callbacks are running on the same thread.

[yiyuanliu]

Yes, this issue needs to be fixed in the future.

One possible way is to call ucp_request_cancel in the drop function.

ucx_request_cancel can't guarantee cancellation safety.

• ucx_request_cancel doesn't cancel send requests. UCX send requests cannot be cancelled openucx/ucx#1162
• If tag recv request is posted to transport layer, ucp_request_cancel need wait request completion. Buffer may still be used during cancellation.