strace 4.15 released

[James Cowgill]

Hi,

On 14/02/17 09:27, Dmitry V. Levin wrote:
> On Mon, Feb 13, 2017 at 04:47:05PM +0000, James Cowgill wrote:
>> On 13/02/17 14:40, Dmitry V. Levin wrote:
>>> 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?
>>
>> uname -m is a bit less hackish:
>>
>> 32-bit kernel: $(uname -m) = mips
>> 64-bit kernel: $(uname -m) = mips64
> 
> No, it didn't work out, 64-bit kernel pretends it's mips:
> http://www.einval.com/debian/strace/build-logs/mipsel/2017-02-14-040242-log-eller-TESTFAIL.txt

Hmm and from the kernel source it looks like you cannot unset
PER_LINUX32 once it's been set:
http://lxr.free-electrons.com/source/arch/mips/kernel/linux32.c#L121

So I don't think there is any nice way to tell.

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20170214/a0cdeeba/attachment.bin>