Bug 767738

Original bug reported here:

http://elrepo.org/bugs/view.php?id=211

Ok. This is obviously not supposed to be happening :) It ought to be that a ksym() dep is generated for dependencies upon other modules, whereas a kernel() dep is generated for core kernel deps. I'll dig into this. I suspect one of these symbols is not being provided by the kernel itself, and is not satisfied by another driver RPM.

As far as I can see, in each case the symbol in question is provided by the kernel, just for some reason it's been incorrectly generated as a ksym() dep rather than kernel() dependency.

Hi Jon,

Just to note I now also have an example package that suffers from the bug this fix was intended to fix - that is a kmod that should generate ksym() deps for symbols provided by other kmods, but actually generates them as kernel() deps with the old redhat-rpm-config-9.0.3-33.el6.noarch package:

$ rpm -qp --requires kmod-asus-wmi-0.0-1.el6.elrepo.i686.rpm | grep sparse
sparse-keymap-kmod
kernel(sparse_keymap_free) = 0x6c72ec05
kernel(sparse_keymap_report_event) = 0x07743244
kernel(sparse_keymap_setup) = 0x4ef28aa7 

instead of:

$ rpm -qp --requires kmod-asus-wmi-0.0-1.el6.elrepo.x86_64.rpm | grep sparse
sparse-keymap-kmod
ksym(sparse_keymap_free) = 0x10229b46
ksym(sparse_keymap_report_event) = 0x8679b20e
ksym(sparse_keymap_setup) = 0x5f5161bb

with the latest redhat-rpm-config-9.0.3-34.el6.noarch

So I now have example packages for both test cases :-)

Links to SRPMs cited in the above examples:

http://elrepo.org/linux/elrepo/el6/SRPMS/fglrx-kmod-11.12-2.el6.elrepo.nosrc.rpm
http://elrepo.org/linux/testing/el6/SRPMS/asus-wmi-kmod-0.0-1.el6.elrepo.src.rpm

Jon,

We (the ELRepo Project) are unable to view https://bugzilla.redhat.com/show_bug.cgi?id=725987 and so are completely in the dark.

Alan.

Ah :) Alan, that is an internal "tracking" bug. I can probably open it up but it has no bearing on this. I am working on getting a fix into 6.3.

I am attaching a patch that I believe will correct the problem. It is caused by a missing "-k1,1" on a sort. The affected script uses sort to produce an ordered list of all kernel symbol deps for a given kernel. Unfortunately, the data is ordered such that symbols for which an internal-only kernel symbol (prefixed with "__") also exists - such as is the case with "kmalloc" and "__kmalloc" - the subsequent attempt to join with other ordered data fails due to the ordering being incorrect. Further, join requires that "LANG=C" be set in order to ensure it will correctly process data that has been sorted (also forced to "LANG=C" for safety) so that it won't regard the data as being incorrectly ordered. I know this isn't a great explanation, but the patch is simple so I hope it makes more sense than this brief explanation.

Created attachment 567474 [details]
fix sort ordering for ksyms

Using this patch I am correctly able to generate "ksym" deps on the asus-wmi driver, and not on the fglrx or ndiswrapper drivers :)

I wonder if either of you wonderful gentlemen could try testing this patch for me today? You can just apply it against /usr/lib/rpm/redhat on a test system, etc.

I've patched find-requires.ksyms, so can do the test.

Many thanks Jon.

Akemi is performing the test builds right now for you :-)

Jon,

I'm happy to report that your patch works fine for all fglrx-kmod, ndiswrapper-kmod and asus-wmi-kmod.

(In reply to comment #11)
> Ah :) Alan, that is an internal "tracking" bug. I can probably open it up but
> it has no bearing on this. I am working on getting a fix into 6.3.

Thanks, Jon. I just wasn't sure of the relevance. As you say it has none, I'm happy to accept that. :)

Seems like I'm the latecomer today . . . best to let Akemi and Ned continue without any assistance from me!

A fix for this bug has been submitted to RHEL6.3.

(In reply to comment #22)
> A fix for this bug has been submitted to RHEL6.3.

Thank you, Jon. Will the bug-fix be fast-tracked, by any chance?

I've gone through the motions of requesting for 6.2...we'll see what can be done :)

(In reply to comment #24)
> I've gone through the motions of requesting for 6.2...we'll see what can be
> done :)

Appreciated. Thank you. ;)

*** Bug 800582 has been marked as a duplicate of this bug. ***

Confirmed this patch has made it into RHEL-6.3 beta:

redhat-rpm-config-9.0.3-39.el6

Not re-tested yet, but assume it's fixed given the included patch is identical to the patch we tested above.

Many thanks Jon.

Hi Jon,

I managed to verify this bug only with ndiswrapper-kmod-1.57-0.1.rc1.el6.elrepo.src.rpm reproducer, but that is tight to x86_64 and i386 architectures.

Don't you have by the chance an universal reproducer that could be used for automated tests? Or it would be great if you could help with creation of a simple spec file that could be used architecture independently.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0911.html