diff mbox series

[for-next,3/3] test range file alloc

Message ID decaf87bd125ad0e77261985e521926aff66ff34.1656580293.git.asml.silence@gmail.com (mailing list archive)
State New
Headers show
Series ranged file slot alloc | expand

Commit Message

Pavel Begunkov June 30, 2022, 9:13 a.m. UTC
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
 test/file-register.c | 171 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 171 insertions(+)

Comments

Jens Axboe June 30, 2022, 1:09 p.m. UTC | #1
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.
Ammar Faizi June 30, 2022, 1:32 p.m. UTC | #2
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.
Pavel Begunkov June 30, 2022, 2:19 p.m. UTC | #3
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.
Ammar Faizi June 30, 2022, 2:31 p.m. UTC | #4
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.
Jens Axboe June 30, 2022, 2:57 p.m. UTC | #5
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.
Pavel Begunkov June 30, 2022, 3:18 p.m. UTC | #6
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".
Eli Schwartz June 30, 2022, 7:26 p.m. UTC | #7
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.)
Jens Axboe June 30, 2022, 8:03 p.m. UTC | #8
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 mbox series

Patch

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;
 }