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]

[Bug runtime/13440] New: cast.exp fails on s390x umod cast in (kernel) begin probe


http://sourceware.org/bugzilla/show_bug.cgi?id=13440

             Bug #: 13440
           Summary: cast.exp fails on s390x umod cast in (kernel) begin
                    probe
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap@sourceware.org
        ReportedBy: mjw@redhat.com
    Classification: Unclassified


cast.exp will fail on s390x with a ERROR: kernel read fault at
0x000000004128dbba (addr) near identifier '@cast' at
.../testsuite/systemtap.base/cast.stp:37:17

This is because that line does:

cast_data = @cast(get_sockaddr(data), "sockaddr", "<sys/socket.h>")->sa_data[0]

make_typequery will see the "<sys/socket.h>" and assume this is a user mode
cast and generates a umod, not a kmod. dwarf_cast_query::handle_query_module()
sees the umod and installs the uderef for user mode address access. This will
then fail (correctly?) fail to access the address as user data.

We could fix the test by using "kernel<linux/socket.h>" which will generate a
kmod instead of a umod. But the comment in the testcase seems to assume you can
use a umod @cast in a begin probe.

I think we should not try to provide user space access in begin/end probes
through casts and the test should be rewritten if it wants to also test umod
casts.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


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