[PATCH v2 0/3] Testsuite fixes for mips64

[Dmitry V. Levin]

On Fri, Aug 12, 2016 at 11:02:14AM +0100, James Cowgill wrote:
[...]
> >> The only test which still seems to fail on my machine is the "pwritev" test,
> >> but I believe that's caused by a kernel bug (which I haven't tracked down yet).
> > 
> > Does this patch changes something with the test result?
> > (also add #include <errno.h> to make it buildable)
> > 
> > --- a/tests/pwritev.c
> > +++ b/tests/pwritev.c
> > @@ -113,6 +113,7 @@ main(void)
> >  		unsigned int n = LEN + 1 - i;
> >  		fputs("pwritev(0, ", stdout);
> >  		print_iovec(iov + i, n, LEN - i);
> > +		errno = 0;
> >  		rc = pwritev(0, iov + i, n, offset + LEN + i);
> >  		printf(", %u, %lld) = %ld %s (%m)\n",
> >  		       n, (long long) offset + LEN + i, rc, errno2name());
> 
> So before it was failing with:
> 10c10
> < pwritev(0, [{iov_base="\1\2\3\4\5\6\7", iov_len=7},
> {iov_base="\2\3\4\5\6\7", iov_len=6}, {iov_base="\3\4\5\6\7",
> iov_len=5}, {iov_base="\4\5\6\7", iov_len=4}, {iov_base="\5\6\7",
> 
> iov_len=3}, {iov_base="\6\7",
>  iov_len=2}, {iov_base="\7", iov_len=1}, 0xfff0fb8000], 8,
> 1004211379570065144) = 27 EFAULT (Bad address)
> ---
> > pwritev(0, [{iov_base="\1\2\3\4\5\6\7", iov_len=7},
> {iov_base="\2\3\4\5\6\7", iov_len=6}, {iov_base="\3\4\5\6\7",
> iov_len=5}, {iov_base="\4\5\6\7", iov_len=4}, {iov_base="\5\6\7",
> 
> iov_len=3}, {iov_base="\6\7",
>  iov_len=2}, {iov_base="\7", iov_len=1}, 0xfff0fb8000], 8,
> 1004211379570065144) = 27
> pwritev.test: failed test: ../strace -e trace=pwritev -a22 -s7 ./pwritev
> output mismatch
> 
> After adding errno = 0 it fails with:
> unknown errno 0

Does this also happen when pwritev is executed without strace?

> How did you know that was where my error was :) I thought it was a
> kernel bug since I think the pwritev call should fail with EFAULT. I
> also noticed that the call only succeeds if the process is being ptraced.

The test tries hard to make this particular syscall end with EFAULT by
passing it an array of struct iovec that starts at mapped memory and ends
at unmapped memory.  As you can see, strace is deliberately unable to
fetch the last element of this array at address 0xfff0fb8000 so it just
prints the address.  This is expected behaviour.  The strange thing is
that the kernel has ignored this obstacle and has returned 27, which is 1
byte less than expected 28 if pwritev was called with 3rd argument set to
7 instead of 8.

So yes, the kernel is really expected to fail with EFAULT, and it looks
like a kernel bug that it doesn't. ;)


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160812/ae9ff38b/attachment.bin>