Bug 677488 - sharedbuf.exp test fails when CONFIG_MODVERSIONS is set
sharedbuf.exp test fails when CONFIG_MODVERSIONS is set
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: systemtap (Show other bugs)
14
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Frank Ch. Eigler
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-14 19:06 EST by Josh Boyer
Modified: 2012-02-03 14:17 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-03 14:17:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
systemtap.log from run on kernel with CONFIG_MODVERSIONS=y (1.68 KB, text/plain)
2011-02-14 19:07 EST, Josh Boyer
no flags Details

  None (edit)
Description Josh Boyer 2011-02-14 19:06:40 EST
Description of problem:

The sharedbuf.exp test fails when CONFIG_MODVERSIONS is set in the running kernel.  It passes without this kernel config option set

Version-Release number of selected component (if applicable):

[jwboyer@r2d2 tmp]$ rpm -qa | grep systemtap
systemtap-runtime-1.4-2.fc14.i686
systemtap-testsuite-1.4-2.fc14.i686
systemtap-1.4-2.fc14.i686
systemtap-sdt-devel-1.4-2.fc14.i686
[jwboyer@r2d2 tmp]$ 

(from updates-testing)

How reproducible:

Always

Steps to Reproduce:
1.  Build a fedora kernel with CONFIG_MODVERSIONS=y
2. cd /usr/share/systemtap/testsuite; make installcheck RUNTESTFLAGS="sharedbuf.exp"
3. Wait for the test to fail
  
Actual results:

                === systemtap Summary ===

# of expected passes            2
# of unexpected failures        1
runtest completed at Mon Feb 14 18:29:13 2011

Expected results:

		=== systemtap Summary ===

# of expected passes		5


Additional info:

I ran this on kernel-2.6.35.11-83.fc14.i686 and it worked fine.  Then I rebuilt the -84 kernel in mock and set CONFIG_MODVERSIONS=y.  That is the only difference between the two kernel configs:

[jwboyer@r2d2 ~]$ diff -Nup /boot/config-2.6.35.11-83.fc14.i686 /boot/config-2.6.35.11-84.fc14.i686 
--- /boot/config-2.6.35.11-83.fc14.i686	2011-02-07 02:09:21.000000000 -0500
+++ /boot/config-2.6.35.11-84.fc14.i686	2011-02-14 16:38:00.000000000 -0500
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.35.11-83.fc14.i686
-# Mon Feb  7 07:03:23 2011
+# Linux kernel version: 2.6.35.11-84.fc14.i686
+# Mon Feb 14 14:04:20 2011
 #
 # CONFIG_64BIT is not set
 CONFIG_X86_32=y
@@ -214,7 +214,7 @@ CONFIG_MODULES=y
 # CONFIG_MODULE_FORCE_LOAD is not set
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_MODULE_FORCE_UNLOAD is not set
-# CONFIG_MODVERSIONS is not set
+CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 CONFIG_STOP_MACHINE=y
 CONFIG_BLOCK=y
[jwboyer@r2d2 ~]$ 

The test fails when booted into the -84 kernel.

My analysis so far is that the testcase has two separately built but dependent modules that get probed and the modversions aren't accounted for in the second module.  The first is the "host" module that loads successfully.  The second is the probe on the hello.stp process, and when systemtap tries to load this module it fails because it didn't include the Module.symvers file from the previous module build.  That results in an error in dmesg like:

[ 1061.938705] wlan0: associated
[ 1604.637976] stap_442845fb230352b68da5d1da4fd4371f_577: systemtap: 1.4/0.151, base: f80c7000, memory: 7data/9text/0ctx/13net/17alloc kb, probes: 1
[ 1611.540520] stap_a4a2da6ea8db8e4ca3bafeaa65548189_723: no symbol version for stp_print_flush_test1
[ 1611.540530] stap_a4a2da6ea8db8e4ca3bafeaa65548189_723: Unknown symbol stp_print_flush_test1 (err -22)
[ 1611.546161] stap_a4a2da6ea8db8e4ca3bafeaa65548189_723: no symbol version for stp_print_flush_test1
[ 1611.546172] stap_a4a2da6ea8db8e4ca3bafeaa65548189_723: Unknown symbol stp_print_flush_test1 (err -22)

I'm not sure how best to approach this, as it would seem to me that something at a more fundamental level needs to be accounted for when CONFIG_MODVERSIONS is set and stap modules are built.
Comment 1 Josh Boyer 2011-02-14 19:07:26 EST
Created attachment 478740 [details]
systemtap.log from run on kernel with CONFIG_MODVERSIONS=y
Comment 2 Frank Ch. Eigler 2012-02-03 14:17:23 EST
This sharedbuf facility is niche enough that MODVERSIONS=y breaking
likely won't upset its users (as it hasn't already).

Note You need to log in before you can comment on or make changes to this bug.