Description of problem: RHTS test /kernel/drivers/3rd-party fail on x86_64 Version-Release number of selected component (if applicable): 2.6.20-14.el5rt How reproducible: Always Steps to Reproduce: 1. Run the /kernel/drivers/3rd-party on x86_64 Actual results: Kernel is not tainted at this time Running GPLModule Module installed: GPLModule Kernel is not tainted at this time GPLModule test Failed: Expected results: This test should pass Additional info: With the same kernel version this test works on i386 but fails on x86_64. Test that passes: http://rhts.lab.boston.redhat.com/cgi-bin/rhts/recipes.cgi?id=73492 ############################################################################### Here is a link to the kernel http://porkchop.redhat.com/brewroot/packages/kernel-rt/2.6.20/14.el5rt/ Here is information on how to setup a local system to use the RHTS devel environment. You can down load the tests from here: http://rhts.lab.boston.redhat.com/rpms/development/noarch/noarch/rh-tests-kernel-drivers-3rd-party-1.9-10.noarch.rpm This test it written for the RHTS environment. So you can install the RHTS devel package following the directions from here: http://intranet.corp.redhat.com/ic/intranet/RHTSMainPage.html then install the test and do a make run. Or if you do _not_ want to install the RHTS devel stuff comment out the following: Makefile # Include a global make rules file include /usr/share/rhts/lib/rhts-make.include runtest.sh # Source the common test script helpers . /usr/bin/rhts_environment.sh then do a make run.
This is failing in the latest kernel 2.6.21-11.el5rt: /kernel/drivers/3rd-party Completed - Fail GPLModule Fail 0 NonGPLModule Fail 0 BadModuleSign Pass 0 GoodModuleSign Pass 0 http://rhts.lab.boston.redhat.com/cgi-bin/rhts/jobs.cgi?id=773&type=Single Recipe 2854
This may be due to the test script making assumptions about its operating environment: (1) /proc/sys/kernel/print-fatal-signals does not appear to exist in the kernel specified, yet CheckUnsignModule() attempts to make use of it. (2) The killme.sh script does not appear to leave anything in the dmesg log, but CheckUnsignModule() appears to rely on it saying something. What kernel were these scripts meant to test?
These scripts were designed for RHEL-5. The execshield patch puts the print-fatal-signals functionality into the kernel. So yeah, if the kernel doesn't have print-fatal-signal, the test won't do much. Unless someone has another way to detect if a 'bad' kernel module tainted the kernel using a userspace app?
Like 253476 perhaps. Jon.
Jon, Do we have any additional data on this issue? Are we going to try and fix it for RT? Jeff
Jeff, This test is really RHEL-5 specific. We should be able to modify it to utilize the output of /proc/modules now. Upstream added a patch to display the taint flags to that proc file. I am working with Jon to backport this to RHEL-5 so we can better test across all the arches. Once those changes are in, we can modify the script to take advantage of the proc file and then the test should automatically become forward compatible (with RT/RHEL-6, etc).
Where do we stand on this bug, wrt RT?
Clark, As discusses on IRC and verbally. This test is of no value to the RT kernel Jeff