strace 4.15 released

[Dmitry V. Levin]

Hi,

On Mon, Jan 09, 2017 at 08:54:52PM +0300, Dmitry V. Levin wrote:
> 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?

OK, there is not going to be any fix for this kernel bug in v4.10,
so I'd rather disable scno tampering tests when MIPS ABI is o32
but the kernel is n64.

Is there any simple way for MIPS o32 userspace to find out whether
the kernel is not a native MIPS o32?  Something less hackish
than manually invoking a MIPS n64 syscall?


-- 
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/20170213/57bce6d0/attachment.bin>