copy_file_range(2): Fix for small values of input file offset and len r366302 broke copy_file_range(2) for small values of input file offset and len. It was possible for rem to be greater than len and then "len - rem" was a large value, since both variables are unsigned. Reported by: koobs, Pablo <pablogsal gmail com> (Python)
Details
Tested via a small C program that did the same test
as the python test that had failed.
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
What sort of function arguments would lead to this problem? It would be good to turn this into an automated test.
It was found with an automated test. I just don't know
the details, except it is python code. I'll forward the
email and koobs@ can fill you in.
The test did the call with *inoffp = 3 and len = 6.
I downloaded the Python script and reproduced the problem. But what should we do about it? The only thing in /usr/tests that exercises copy_file_range is the fusefs test suite. A regression test for this bug certainly doesn't belong there. There's pjdfstest, though I find its TAP-based design cumbersome. I suppose I could extract fusefs's copy_file_range tests into a standalone ATF test that exercises TMPDIR. What did you use for testing when you developed copy_file_range?
I have a few C programs, which could be cleaned up.
But I know nothing about automated testing nor
what FreeBSD currently does.
I recall someone did not like the fact it used
random number generators for arguments for
part of the tests. The rest were "corner cases"
although I don't recall if I had a "small offset+small len"
case.
I probably did not do a full test exercise for the
commit that caused this breakage.
Let's commit this then, and not wait for a proper test suite. We'll keep discussing that in the mail thread I included you on.