On 2018-06-03 10:09 AM, Helge Deller wrote:
On 02.06.2018 17:01, John David Anglin wrote:
On 2018-06-02 4:35 AM, Dominique Dumont wrote:
On Sun, 27 May 2018 17:35:40 -0400 John David Anglin<[email protected]>
wrote:
The value of r in the failing assertion is -233. If the value is a standard
errno, it is ENOBUFS.
No.
The value of r in the failing assertion is -223, which is -EOPNOTSUPP.
# r is -223 UV_ENOTSUP=-252 and EOPNOTSUPP=-223
You are correct. I think I'm getting dyslexic.
The test used to pass with 1.18.0, so the problem appears to be a regression in
libuv1. I would
guess that the failure was introduced by the following change:
https://github.com/libuv/libuv/commit/3ae88200d6f52ea7b3d8ff9b8164adde65f6c43a
The failure line corresponds to this addition.
The change mentions that an error will be returned if the platform doesn't
support copy-on-write.
I tend to think there's an issue with the error codes either in the kernel or
libuv1. I doubt we are
actually running out of memory.
The problem is, that on parisc ENOTSUP and EOPNOTSUPP have different values,
which breaks the checks.
Other arches, e.g. x86-64 seem to have the same value for both, so there the
check doesn't break.
test-fs-copyfile.c checks for UV_ENOTSUP (which is ENOTSUP), while in src/unix/fs.c is
checked against "errno != EOPNOTSUPP".
This needs to be fixed in libuv1.
The attached patch is just a workaround.
According to this manpage, the kernel returns EOPNOTSUPP, not ENOTSUP:
http://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html
So, the test is wrong to check UV_ENOTSUP (ENOTSUP).
Thanks,
Dave
--
John David Anglin [email protected]
