This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: exercising current aarch64 kprobe support with systemtap


On 08/17/2016 01:27 PM, William Cohen wrote:
> On 08/17/2016 02:04 PM, David Smith wrote:
>> On 08/17/2016 09:36 AM, William Cohen wrote:
>>> Hi,
>>>
>>> I was able to locally build uptream_arm64-devel branch of  
>>> https://github.com/pratyushanand/linux.git with the configure
>>> from fedora rawhide and run the systemtap tests. Pratyush were
>>> there changes in patches between these versions?  The only other
>>> difference is that the machine above was a fedora 24 machine rather
>>> than a RHELSA, so there would be differences in the compiler and
>>> other tools. The results (systemtap.log and systemtap.sum) are at:
>>>
>>> http://people.redhat.com/wcohen/aarch64/20160817/
>>
>> ... stuff deleted ...
>>
>>> There are also some differences in the syscalls used on aarch64 that
>>> cause some of the tests to fail.
>>
>> I looked a bit at those syscall failures, and I'm not sure what is going
>> on. Note that the syscall/nd_syscall test cases pass completely on RHEL7
>> aarch64. I did see one easy fix - you were getting registration errors
>> for the sched_[gs]etaffinity syscalls. Commit 619425f makes them fully
>> optional.
> 
> The functions are actually there otherwise the error would happen during the
> earlier passes. The kprobes registration errors are due to the the heuristic
> that scans backward through the instructions to make sure that the
kprobe is
> not in an atomic region. The heuristic got past the beginning of the function
> and interprets some of the data before the start of the function as
the start
> of an atomic region.  There is a proposed fix for this, but it is not
in this
> particular kernel.
> 
> There are some syscalls that either are a bit different in implentation or do
> not fail in the same way as x86 that are causing some of the tests to
fail.
> For example syscall.fork doesn't seem to be implemented on aarch64 and
setgroups
> return 0 rather than an error for some argument combinations.

OK, here's the status of the [nd_]syscall test failures. There were 2
failures caused by a test case being too specific when looking for
syscall return value. There were fixed by commit 9c004b0:

FAIL: 64-bit getgroups syscall
FAIL: 64-bit setgroups syscall

There are 4 failures caused by the atomic region kprobes registration bug:

FAIL: 64-bit sched syscall
FAIL: 64-bit sched_setaffinity syscall
FAIL: 64-bit sched_setscheduler syscall
FAIL: 64-bit set_tid_address syscall

I verified all these failures by trying to use perf to put a probe on
the same functions:

====
# perf probe --add=sys_set_tid_address
Failed to write event: Invalid argument
  Error: Failed to add events.
====

I'm not seeing any issue with fork in the testsuite results, but perhaps
I've missed something. What error are you referring to?

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]