Handle interrupts in __ublksrv_ctrl_cmd #79
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The syscall
io_uring_enter
may return EINTR if it is interrupted by a delivery of a signal. This was happening to me recently; I saw that theSIG_PROF
signal fired periodically, which would fail theublksrv_ctrl_start_dev()
call (returns -EINTR). The signal is firing due to unrelated circumstances.Since __ublksrv_ctrl_cmd already added an SQE, it's easier for ublksrv to handle the error instead of the caller.
Note that I only added support to
__ublksrv_ctrl_cmd
since control commands are likely to be done once on startup. io_urings for handling IO are already expected to loop for IO, so there's no need for ublksrv to explicitly handle theEINTR
.Currently the code loops indefinitely. I'm also considering it best practice to set some maximum retry number or timeout, but I wanted to get your opinion first.
Also I thought about using
TEMP_FAILURE_RETRY
but the semantics fromio_uring_wait_cqe
are a bit different.TEMP_FAILURE_RETRY
expects the return code to be-1
and then checkserrno
, butio_uring_wait_cqe
returns -EINTR directly, so the do while loop is necessary.