strace 4.15 released

[Dmitry V. Levin]

Hi,

On Mon, Jan 09, 2017 at 05:31:37PM +0000, James Cowgill wrote:
> On 06/01/17 00:51, Dmitry V. Levin wrote:
> > On Tue, Jan 03, 2017 at 06:02:44PM +0000, James Cowgill wrote:
> >> On 20/12/16 00:36, Steve McIntyre wrote:
> >>> On Tue, Dec 20, 2016 at 03:16:17AM +0300, Dmitry V. Levin wrote:
> >>>> On Tue, Dec 20, 2016 at 12:50:29AM +0100, Nahim El Atmani wrote:
> >>>>> On Mon, 19 Dec 2016 18:30:29 +0000, Steve McIntyre wrote:
> >>>>>> I'm seeing test suite failures on mips[1], mipsel[2] and mips64el[3]
> >>>>>> on Debian machines.
> >>>>>>
> >>>>>> The 32-bit builds are both showing issues with fault injection. I
> >>>>>> can't follow what the code is meant to be doing here, so no
> >>>>>> ideas on what's wrong. :-(
> >>>>>
> >>>>> As Dmitry said earlier:
> >>>>>
> >>>>> On Tue, 15 Nov 2016 15:43:59 +0300, Dmitry V. Levin wrote:
> >>>>>> Well, the mips kernel does not implement substitution of syscall numbers
> >>>>>
> >>>>> So it looks like the test has failed to SKIP on this target.
> >>>>
> >>>> As I'm not 100% sure there is no kernel support for mips, I decided
> >>>> not to skip the test on mips until somebody investigates.
> >>>
> >>> Ah, OK. James Cowgill is my friendly local mips expert - let's see
> >>> what he thinks... :-)
> >>
> >> I've had a look and I think there is a kernel bug here - specifically
> >> affecting 32-bit programs run on 64-bit kernels (like all the Debian
> >> buildds and the porterbox are). An extra PTRACE_SYSCALL stop is
> >> happening which confuses everything. I'll look some more tomorrow.
> > 
> > Indeed, it seems to be a kernel bug in scall64-o32.S and scall64-n32.S.
> > 
> > According to current arch/mips/kernel/scall64-o32.S:trace_a_syscall
> > (the same applies to arch/mips/kernel/scall64-n32.S),
> > 
> > if the syscall number after the first syscall_trace_enter call is out
> > of range, there is a jump to not_o32_scall which in turn jumps to
> > arch/mips/kernel/scall64-64.S:handle_sys64 (or to handle_sysn32 which
> > then jumps on to handle_sys64).
> > 
> > Handle_sys64, unsurprisingly, does all over again, starting with
> > a syscall_trace_enter call, which appears to be the second one
> > and causes that extra syscall stop you observe with 32-bit tracees
> > running on 64-bit kernels.
> 
> Just going through all the MIPS testsuite bugs again:
> 
> fault_injection*
> The kernel bug above (no patch yet).

I couldn't find an easy fix for this kernel bug.  Any ideas?

> readahead
> glibc bug fixed in 2.25
> https://sourceware.org/bugzilla/show_bug.cgi?id=21026

I applied a workaround for this: v4.15-266-ge752ef6.

> pwritev
> I debugged this to an Octeon specific kernel bug in Octeon's optimized
> copy_from_memory implementation :S I've sent a patch to the linux-mips
> list to fix this.
> https://www.linux-mips.org/archives/linux-mips/2017-01/msg00094.html

Great.

> newfstatat
> Firstly we need to define TEST_BOGUS_STRUCT_STAT somewhere otherwise the
> test just segfaults in glibc.

Could you send a patch for this, please?

> After that it suffers from the negative dates problem which happens when
> glibc copies struct stat on mips n64. I thought I fixed this - did
> something change?

There was a big rework of struct stat{,64} decoding, see commit
v4.13-80-ga7c4ee4.  I reverted that workaround for mips n64 (commit
v4.13-81-g6fc5338) as I believe it's no longer needed, otherwise other
related tests would fail.


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