Message ID | decaf87bd125ad0e77261985e521926aff66ff34.1656580293.git.asml.silence@gmail.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | ranged file slot alloc | expand |
On 6/30/22 3:13 AM, Pavel Begunkov wrote: > @@ -949,5 +1114,11 @@ int main(int argc, char *argv[]) > return ret; > } > > + ret = test_file_alloc_ranges(); > + if (ret) { > + printf("test_partial_register_fail failed\n"); > + return ret; > + } If you're returning this directly, test_file_alloc_ranges() should use the proper T_EXIT_foo return codes.
On 6/30/22 8:09 PM, Jens Axboe wrote: > On 6/30/22 3:13 AM, Pavel Begunkov wrote: >> @@ -949,5 +1114,11 @@ int main(int argc, char *argv[]) >> return ret; >> } >> >> + ret = test_file_alloc_ranges(); >> + if (ret) { >> + printf("test_partial_register_fail failed\n"); >> + return ret; >> + } > > If you're returning this directly, test_file_alloc_ranges() should use > the proper T_EXIT_foo return codes. Also use `fprintf(stderr, ...)` instead of `printf(...)` for that one.
On 6/30/22 14:09, Jens Axboe wrote: > On 6/30/22 3:13 AM, Pavel Begunkov wrote: >> @@ -949,5 +1114,11 @@ int main(int argc, char *argv[]) >> return ret; >> } >> >> + ret = test_file_alloc_ranges(); >> + if (ret) { >> + printf("test_partial_register_fail failed\n"); >> + return ret; >> + } > > If you're returning this directly, test_file_alloc_ranges() should use > the proper T_EXIT_foo return codes. Nobody cared enough to "fix" all tests to use those new codes, most of the cases just return what they've got, but whatever. Same with stdout vs stderr.
On 6/30/22 9:19 PM, Pavel Begunkov wrote: > On 6/30/22 14:09, Jens Axboe wrote: >> On 6/30/22 3:13 AM, Pavel Begunkov wrote: >>> @@ -949,5 +1114,11 @@ int main(int argc, char *argv[]) >>> return ret; >>> } >>> + ret = test_file_alloc_ranges(); >>> + if (ret) { >>> + printf("test_partial_register_fail failed\n"); >>> + return ret; >>> + } >> >> If you're returning this directly, test_file_alloc_ranges() should use >> the proper T_EXIT_foo return codes. > > Nobody cared enough to "fix" all tests to use those new codes, most > of the cases just return what they've got, but whatever. Same with > stdout vs stderr. That error code rule was invented since commit: 68103b731c34a9f83c181cb33eb424f46f3dcb94 ("Merge branch 'exitcode-protocol' of ....") Ref: https://github.com/axboe/liburing/pull/621/files Thanks to Eli who did it. Eli also fixed all tests. Maybe some are still missing, but if we find it, better to fix it.
On 6/30/22 8:19 AM, Pavel Begunkov wrote: > On 6/30/22 14:09, Jens Axboe wrote: >> On 6/30/22 3:13 AM, Pavel Begunkov wrote: >>> @@ -949,5 +1114,11 @@ int main(int argc, char *argv[]) >>> return ret; >>> } >>> + ret = test_file_alloc_ranges(); >>> + if (ret) { >>> + printf("test_partial_register_fail failed\n"); >>> + return ret; >>> + } >> >> If you're returning this directly, test_file_alloc_ranges() should use >> the proper T_EXIT_foo return codes. > > Nobody cared enough to "fix" all tests to use those new codes, most > of the cases just return what they've got, but whatever. Same with > stdout vs stderr. We'll get there eventually, it's just a bad idea to add NEW tests that don't adhere to the new rules. As for stdout vs stderr, by far most of them do it correct. Again, new tests certainly should.
On 6/30/22 15:31, Ammar Faizi wrote: > On 6/30/22 9:19 PM, Pavel Begunkov wrote: >> On 6/30/22 14:09, Jens Axboe wrote: >>> On 6/30/22 3:13 AM, Pavel Begunkov wrote: >>>> @@ -949,5 +1114,11 @@ int main(int argc, char *argv[]) >>>> return ret; >>>> } >>>> + ret = test_file_alloc_ranges(); >>>> + if (ret) { >>>> + printf("test_partial_register_fail failed\n"); >>>> + return ret; >>>> + } >>> >>> If you're returning this directly, test_file_alloc_ranges() should use >>> the proper T_EXIT_foo return codes. >> >> Nobody cared enough to "fix" all tests to use those new codes, most >> of the cases just return what they've got, but whatever. Same with >> stdout vs stderr. > > That error code rule was invented since commit: > > 68103b731c34a9f83c181cb33eb424f46f3dcb94 ("Merge branch 'exitcode-protocol' of ....") > > Ref: https://github.com/axboe/liburing/pull/621/files > > Thanks to Eli who did it. Eli also fixed all tests. Maybe some are still > missing, but if we find it, better to fix it. Have no idea what you're talking about but I'm having hard time calling 6 returns out of 21 in this file "all".
On 6/30/22 11:18 AM, Pavel Begunkov wrote: > On 6/30/22 15:31, Ammar Faizi wrote: >> On 6/30/22 9:19 PM, Pavel Begunkov wrote: >>> Nobody cared enough to "fix" all tests to use those new codes, most >>> of the cases just return what they've got, but whatever. Same with >>> stdout vs stderr. >> >> That error code rule was invented since commit: >> >> 68103b731c34a9f83c181cb33eb424f46f3dcb94 ("Merge branch >> 'exitcode-protocol' of ....") >> >> Ref: https://github.com/axboe/liburing/pull/621/files >> >> Thanks to Eli who did it. Eli also fixed all tests. Maybe some are still >> missing, but if we find it, better to fix it. > > Have no idea what you're talking about but I'm having > hard time calling 6 returns out of 21 in this file "all". Hi, I should probably clarify the state of affairs... I submitted a patch series on github 4 days ago which implements those new codes. It was merged 2 days ago. This is very new code, so I think it's not completely 100% fair to say that no one "cared" enough to use it. As far as the actual changes and their completion go... take a look at the commit messages in the merged patches, specifically take a look at commit ed430fbeb33367324a039d9cee0fd504bb91e11a. """ tests: migrate some tests to use enum-based exit codes [...] A partial migration of existing pass/fail values in test sources is included. """ You can also take a look at Github's equivalent of a cover letter, in which I mentioned that I haven't ported everything, but what I did do is still useful because "a) it has to start somewhere, b) it demonstrates the basic idea of how to structure things." As far as I'm concerned, I believe the patch series stands on its own merit. I established the framework to use, and that on its own is useful and deserves merging, because it means that people can start using it, and getting things correct from the beginning when adding new code. Old code does need to be carefully checked, it's not a simple find/replace, but that can be done incrementally, and I'm willing to continue work on that myself. I just don't think it has to be all or nothing at the time of merging. ... Also, for the record -- while waiting for the Github patch series to be merged, I did continue to convert more code via git commit --fixup= && git rebase -i --autosquash. If it had taken longer to end up being merged, I would have ended up converting more tests over, and that would have reflected on the current state of git master. I'm not sad that it got merged when it was, because again, this work can be done incrementally and people can take advantage of existing work immediately. Jens decided it was ready to merge, and that seems like a fine decision to me. If he had asked me to finish porting all the tests first, I could have done that too. More will get done in short order. I'm not even a bottleneck for doing it. :) (Though I will work on it.)
On 6/30/22 1:26 PM, Eli Schwartz wrote: > On 6/30/22 11:18 AM, Pavel Begunkov wrote: >> On 6/30/22 15:31, Ammar Faizi wrote: >>> On 6/30/22 9:19 PM, Pavel Begunkov wrote: >>>> Nobody cared enough to "fix" all tests to use those new codes, most >>>> of the cases just return what they've got, but whatever. Same with >>>> stdout vs stderr. >>> >>> That error code rule was invented since commit: >>> >>> 68103b731c34a9f83c181cb33eb424f46f3dcb94 ("Merge branch >>> 'exitcode-protocol' of ....") >>> >>> Ref: https://github.com/axboe/liburing/pull/621/files >>> >>> Thanks to Eli who did it. Eli also fixed all tests. Maybe some are still >>> missing, but if we find it, better to fix it. >> >> Have no idea what you're talking about but I'm having >> hard time calling 6 returns out of 21 in this file "all". > > > Hi, I should probably clarify the state of affairs... > > I submitted a patch series on github 4 days ago which implements those > new codes. It was merged 2 days ago. This is very new code, so I think > it's not completely 100% fair to say that no one "cared" enough to use it. > > As far as the actual changes and their completion go... take a look at > the commit messages in the merged patches, specifically take a look at > commit ed430fbeb33367324a039d9cee0fd504bb91e11a. > > """ > tests: migrate some tests to use enum-based exit codes > > [...] > > A partial migration of existing pass/fail values in test sources is > included. > """ > > You can also take a look at Github's equivalent of a cover letter, in > which I mentioned that I haven't ported everything, but what I did do is > still useful because "a) it has to start somewhere, b) it demonstrates > the basic idea of how to structure things." > > As far as I'm concerned, I believe the patch series stands on its own > merit. I established the framework to use, and that on its own is useful > and deserves merging, because it means that people can start using it, > and getting things correct from the beginning when adding new code. > > Old code does need to be carefully checked, it's not a simple > find/replace, but that can be done incrementally, and I'm willing to > continue work on that myself. I just don't think it has to be all or > nothing at the time of merging. > > > ... > > Also, for the record -- while waiting for the Github patch series to be > merged, I did continue to convert more code via git commit --fixup= && > git rebase -i --autosquash. If it had taken longer to end up being > merged, I would have ended up converting more tests over, and that would > have reflected on the current state of git master. > > I'm not sad that it got merged when it was, because again, this work can > be done incrementally and people can take advantage of existing work > immediately. Jens decided it was ready to merge, and that seems like a > fine decision to me. If he had asked me to finish porting all the tests > first, I could have done that too. And that was why I merged it, too. I think it's a step in the right direction, and as long as you keep converting tests so we end up in a cohesive state, then that's all good. I just did a liburing release and it'll be at least few months before the next one, now is a good time to shake up things like this. Thanks for your work so far, looking forward to the next batch!
diff --git a/test/file-register.c b/test/file-register.c index cd00a90..dc4e685 100644 --- a/test/file-register.c +++ b/test/file-register.c @@ -9,6 +9,7 @@ #include <stdlib.h> #include <string.h> #include <fcntl.h> +#include <limits.h> #include <sys/resource.h> #include "helpers.h" @@ -830,6 +831,170 @@ static int test_partial_register_fail(void) return 0; } +static int file_update_alloc(struct io_uring *ring, int *fd) +{ + struct io_uring_sqe *sqe; + struct io_uring_cqe *cqe; + int ret; + + sqe = io_uring_get_sqe(ring); + io_uring_prep_files_update(sqe, fd, 1, IORING_FILE_INDEX_ALLOC); + + ret = io_uring_submit(ring); + if (ret != 1) { + fprintf(stderr, "%s: got %d, wanted 1\n", __FUNCTION__, ret); + return -1; + } + + ret = io_uring_wait_cqe(ring, &cqe); + if (ret < 0) { + fprintf(stderr, "%s: io_uring_wait_cqe=%d\n", __FUNCTION__, ret); + return -1; + } + ret = cqe->res; + io_uring_cqe_seen(ring, cqe); + return ret; +} + +static int test_out_of_range_file_ranges(struct io_uring *ring) +{ + int ret; + + ret = io_uring_register_file_alloc_range(ring, 8, 3); + if (ret != -EINVAL) { + fprintf(stderr, "overlapping range %i\n", ret); + return 1; + } + + ret = io_uring_register_file_alloc_range(ring, 10, 1); + if (ret != -EINVAL) { + fprintf(stderr, "out of range index %i\n", ret); + return 1; + } + + ret = io_uring_register_file_alloc_range(ring, 7, ~1U); + if (ret != -EOVERFLOW) { + fprintf(stderr, "overflow %i\n", ret); + return 1; + } + + return 0; +} + +static int test_overallocating_file_range(struct io_uring *ring, int fds[2]) +{ + int roff = 7, rlen = 2; + int ret, i, fd; + + ret = io_uring_register_file_alloc_range(ring, roff, rlen); + if (ret) { + fprintf(stderr, "io_uring_register_file_alloc_range %i\n", ret); + return 1; + } + + for (i = 0; i < rlen; i++) { + fd = fds[0]; + ret = file_update_alloc(ring, &fd); + if (ret != 1) { + fprintf(stderr, "file_update_alloc\n"); + return 1; + } + + if (fd < roff || fd >= roff + rlen) { + fprintf(stderr, "invalid off result %i\n", fd); + return 1; + } + } + + fd = fds[0]; + ret = file_update_alloc(ring, &fd); + if (ret != -ENFILE) { + fprintf(stderr, "overallocated %i, off %i\n", ret, fd); + return 1; + } + + return 0; +} + +static int test_zero_range_alloc(struct io_uring *ring, int fds[2]) +{ + int ret, fd; + + ret = io_uring_register_file_alloc_range(ring, 7, 0); + if (ret) { + fprintf(stderr, "io_uring_register_file_alloc_range failed %i\n", ret); + return 1; + } + + fd = fds[0]; + ret = file_update_alloc(ring, &fd); + if (ret != -ENFILE) { + fprintf(stderr, "zero alloc %i\n", ret); + return 1; + } + return 0; +} + +static int test_file_alloc_ranges(void) +{ + struct io_uring ring; + int ret, pipe_fds[2]; + + if (pipe(pipe_fds)) { + fprintf(stderr, "pipes\n"); + return 1; + } + ret = io_uring_queue_init(8, &ring, 0); + if (ret) { + fprintf(stderr, "queue_init: %d\n", ret); + return 1; + } + + ret = io_uring_register_files_sparse(&ring, 10); + if (ret == -EINVAL) { +not_supported: + close(pipe_fds[0]); + close(pipe_fds[1]); + io_uring_queue_exit(&ring); + printf("file alloc ranges are not supported, skip\n"); + return 0; + } else if (ret) { + fprintf(stderr, "io_uring_register_files_sparse %i\n", ret); + return ret; + } + + ret = io_uring_register_file_alloc_range(&ring, 0, 1); + if (ret) { + if (ret == -EINVAL) + goto not_supported; + fprintf(stderr, "io_uring_register_file_alloc_range %i\n", ret); + return 1; + } + + ret = test_overallocating_file_range(&ring, pipe_fds); + if (ret) { + fprintf(stderr, "test_overallocating_file_range() failed\n"); + return 1; + } + + ret = test_out_of_range_file_ranges(&ring); + if (ret) { + fprintf(stderr, "test_out_of_range_file_ranges() failed\n"); + return 1; + } + + ret = test_zero_range_alloc(&ring, pipe_fds); + if (ret) { + fprintf(stderr, "test_zero_range_alloc() failed\n"); + return 1; + } + + close(pipe_fds[0]); + close(pipe_fds[1]); + io_uring_queue_exit(&ring); + return 0; +} + int main(int argc, char *argv[]) { struct io_uring ring; @@ -949,5 +1114,11 @@ int main(int argc, char *argv[]) return ret; } + ret = test_file_alloc_ranges(); + if (ret) { + printf("test_partial_register_fail failed\n"); + return ret; + } + return T_EXIT_PASS; }
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> --- test/file-register.c | 171 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+)