From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13356 invoked by alias); 23 Jul 2013 19:02:41 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 13283 invoked by uid 48); 23 Jul 2013 19:02:37 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/15775] New: relay host/guest functionality is broken on RHEL6 Date: Tue, 23 Jul 2013 19:02:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dsmith at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-q3/txt/msg00047.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15775 Bug ID: 15775 Summary: relay host/guest functionality is broken on RHEL6 Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: runtime Assignee: systemtap at sourceware dot org Reporter: dsmith at redhat dot com On RHEL6, the systemtap.printf/sharedbuf.exp test fails: ==== Running /es/scratch/dsmith/systemtap/src/testsuite/systemtap.printf/sharedbuf.exp ... spawn stap /es/scratch/dsmith/systemtap/src/testsuite/systemtap.printf/sharedbuf.stp -DRELAY_HOST=test1 Host: begin PASS: shared buffer hosting WARNING: "stp_print_flush_test1" [/tmp/stap3qLPPW/stap_3afb871f7052c2f8b13ef4bc30d1f01a_1033.ko] undefined! ERROR: Couldn't insert module '/tmp/stap3qLPPW/stap_3afb871f7052c2f8b13ef4bc30d1f01a_1033.ko': Unknown symbol in module WARNING: /usr/local/bin/staprun exited with status: 1 Pass 5: run failed. [man error::pass5] PASS: shared buffer guest FAIL: buffer sharing (1, 0) testcase /es/scratch/dsmith/systemtap/src/testsuite/systemtap.printf/sharedbuf.exp completed in 127 seconds ==== In /var/log/messages, you'll see this: ==== Jul 23 13:03:09 kvm-el6-64-1 kernel: stap_2a284551e36db9394c1f2b499dfa812_12005: no symbol version for stp_print_flush_test1 Jul 23 13:03:09 kvm-el6-64-1 kernel: stap_2a284551e36db9394c1f2b499dfa812_12005: Unknown symbol stp_print_flush_test1 ==== I believe this is happening because of kernel symbol versioning. When the 2nd module gets built, is doesn't have access to the Module.symvers from the 1st module. Here's what the kernel's Documentation/kbuild/modules.txt file says about symbol versioning: ==== --- 6.3 Symbols From Another External Module Sometimes, an external module uses exported symbols from another external module. kbuild needs to have full knowledge of all symbols to avoid spliitting out warnings about undefined symbols. Three solutions exist for this situation. NOTE: The method with a top-level kbuild file is recommended but may be impractical in certain situations. Use a top-level kbuild file If you have two modules, foo.ko and bar.ko, where foo.ko needs symbols from bar.ko, you can use a common top-level kbuild file so both modules are compiled in the same build. Consider the following directory layout: ./foo/ <= contains foo.ko ./bar/ <= contains bar.ko The top-level kbuild file would then look like: #./Kbuild (or ./Makefile): obj-y := foo/ bar/ And executing $ make -C $KDIR M=$PWD will then do the expected and compile both modules with full knowledge of symbols from either module. Use an extra Module.symvers file When an external module is built, a Module.symvers file is generated containing all exported symbols which are not defined in the kernel. To get access to symbols from bar.ko, copy the Module.symvers file from the compilation of bar.ko to the directory where foo.ko is built. During the module build, kbuild will read the Module.symvers file in the directory of the external module, and when the build is finished, a new Module.symvers file is created containing the sum of all symbols defined and not part of the kernel. Use "make" variable KBUILD_EXTRA_SYMBOLS If it is impractical to copy Module.symvers from another module, you can assign a space separated list of files to KBUILD_EXTRA_SYMBOLS in your build file. These files will be loaded by modpost during the initialization of its symbol tables. ==== Based on that, I tried using the 3rd solution. In one terminal for the server: ==== # stap -p4 -k testsuite/systemtap.printf/sharedbuf.stp -DRELAY_HOST=test1 stap_14594.ko Keeping temporary directory "/tmp/stapie3sXR" # staprun /tmp/stapie3sXR/stap_14594.ko Host: begin HelloWorld ==== In another terminal for the client. Notice I try first without setting 'KBUILD_EXTRA_SYMBOLS'. ==== # stap testsuite/systemtap.printf/hello.stp -DRELAY_GUEST=test1 ERROR: Couldn't insert module '/tmp/stapYX78X6/stap_2a284551e36db9394c1f2b499dfa812b_1006.ko': Unknown symbol in module WARNING: /usr/local/bin/staprun exited with status: 1 Pass 5: run failed. [man error::pass5] # KBUILD_EXTRA_SYMBOLS=/tmp/stapie3sXR/Module.symvers stap --disable-cache -v testsuite/systemtap.printf/hello.stp -DRELAY_GUEST=test1 Pass 1: parsed user script and 95 library script(s) using 200112virt/26232res/2936shr/23760data kb, in 180usr/20sys/196real ms. Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) using 200640virt/27016res/3208shr/24288data kb, in 0usr/0sys/5real ms. Pass 3: translated to C into "/tmp/stap7CL6zk/stap_14836_src.c" using 200764virt/27252res/3428shr/24412data kb, in 0usr/0sys/1real ms. Pass 4: compiled C into "stap_14836.ko" in 6950usr/1220sys/8715real ms. Pass 5: starting run. Pass 5: run completed in 20usr/30sys/318real ms. ==== Strangely enough sharedbuf.exp passes on rawhide (3.11.0-0.rc0.git7.1.fc20.x86_64). -- You are receiving this mail because: You are the assignee for the bug.