-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
io_uring: don't assume completions order #20224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
We are posting two submission (zero copy send and receive) and then reading two completions. There is no guarantee that those completions will be in the order of submissions. This test was expecting fist send completion then receive. Fix is allowing them to come other way too.
|
Thanks! |
|
Still getting failures: |
|
I am seeing this order; and in consideration of |
In my first [try](ziglang#20224) to fix 20212 I didn't reproduce bug on required kernel (6.9.2) and wrongly concluded that first two completions have different order on newer kernel. On my current kernel (6.5.0) order of completions is: send1, recv, send2. On 6.9.2 order is send1, send2, recv. This fix allows second two completions to arrive in any order. Tested on both kernels. Fixes: ziglang#20212
|
Uf, sorry for wasting your time. In the first try I didn't make an effort to reproduce bug on the required kernel and made wrong conclusion about what completions have different order on newer kernel. Here is new PR which is tested on 6.9.2 kernel. |
In my first [try](#20224) to fix 20212 I didn't reproduce bug on required kernel (6.9.2) and wrongly concluded that first two completions have different order on newer kernel. On my current kernel (6.5.0) order of completions is: send1, recv, send2. On 6.9.2 order is send1, send2, recv. This fix allows second two completions to arrive in any order. Tested on both kernels. Fixes: #20212
In my first [try](ziglang#20224) to fix 20212 I didn't reproduce bug on required kernel (6.9.2) and wrongly concluded that first two completions have different order on newer kernel. On my current kernel (6.5.0) order of completions is: send1, recv, send2. On 6.9.2 order is send1, send2, recv. This fix allows second two completions to arrive in any order. Tested on both kernels. Fixes: ziglang#20212
In my first [try](ziglang#20224) to fix 20212 I didn't reproduce bug on required kernel (6.9.2) and wrongly concluded that first two completions have different order on newer kernel. On my current kernel (6.5.0) order of completions is: send1, recv, send2. On 6.9.2 order is send1, send2, recv. This fix allows second two completions to arrive in any order. Tested on both kernels. Fixes: ziglang#20212
We are posting two submissions (zero copy send and receive) and then reading two completions. There is no guarantee that those completions will be in the order of submissions.
This test was expecting fist send completion then receive. Fix is allowing them to come the other way too.
Fixes: #20212