This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
ARM linux-3.11.1-300.fc19.armv7hl incorrect handling uint16_t in probe_kernel_read() probe_kernel_write() functions
- From: William Cohen <wcohen at redhat dot com>
- To: arm at lists dot fedoraproject dot org, "systemtap at sourceware dot org" <systemtap at sourceware dot org>
- Date: Thu, 24 Oct 2013 16:30:11 -0400
- Subject: ARM linux-3.11.1-300.fc19.armv7hl incorrect handling uint16_t in probe_kernel_read() probe_kernel_write() functions
- Authentication-results: sourceware.org; auth=none
Hello Everyone,
I was reviewing the systemtap testsuite results for ARM on Fedora 19 and I found that one of the tests (systemtap.base/deref.stp) failing on ARM for uint16_t reads and writes. The same tests work on x86_64. There appears to be ARM specific code in linux/arch/arm/include/asm/uaccess.h to read and write memory. I suspect that the 16-bit case for copies isn't being handled correctly.
The issue can be observed by
# yum install kernel-devel systemtap-testsuite -y
# debuginfo-install kernel-`uname -r` -y
$ uname -a
Linux dhcp129-3.rdu.redhat.com 3.11.1-300.fc19.armv7hl #1 SMP Thu Sep 19 16:31:05 EDT 2013 armv7l armv7l armv7l GNU/Linux
$ rpm -q systemtap
systemtap-2.3-1.fc19.armv7hl
$cd /usr/share/systemtap/testsuite
$sudo make installcheck RUNTESTFLAGS="--debug systemtap.base/deref.exp"
On ARM Fedora 19 The tests reports some failures:
=== systemtap Summary ===
# of expected passes 2
# of unexpected failures 1
Looking at the systemtap.log shows the tests starting up, but the 16-bit read/write operations failing:
PASS: ./systemtap.base/deref.stp startup
PASS: ./systemtap.base/deref.stp load generation
systemtap ending probe
systemtap test failure - kread u16
systemtap test failure - kread const u16
systemtap test failure - kwrite u16
On x86_64 the tests all passed:
=== systemtap Summary ===
# of expected passes 6
I modified the deref.stp script to see precisely what the arm machine was reasing and writing. It looked like it only got the lower 8-bits of the 16-bit quanity correct. The uper 8-bits are non-zero but it isn't clear where those values are coming from.
-Will