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)
Tested via a small C program that did the same test
as the python test that had failed.
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"
I probably did not do a full test exercise for the
commit that caused this breakage.