Description of problem: The symsets tarballs included in the kernel-devel packages do *not* cover all symbols available in the kernel. Building a kernel module against these symbols creates packages with the wrong requirements that *must* be met, but cannot be by the kernel packages . kernel(rhel5_net_ethernet_ga) = 9c3c45aebe364e710f059016c591287b76553c11 ksym(napi_gro_flush) = db2247bc <------------------------ kernel(rhel5_drivers_char_ga) = 9825f97c6773e4d766359d55afa360b0c31cd1a6 kernel(rhel5_net_core_u4) = 833236420370073f165b26ec2d5d17ae7b10024a . napi_gro_flush is a symbol supported by the current kernel, but it's not represented in the symsets file: [root@localhost i686]# cat /proc/kallsyms |grep napi_gro c05c0e1c t napi_gro_complete c05c1083 t __napi_gro_receive c05c112d T napi_gro_frags c05c115a T napi_gro_receive c05c1179 T napi_gro_flush [root@localhost 2.6.18-194.el5-i686]# pwd /usr/src/kernels/2.6.18-194.el5-i686 [root@localhost 2.6.18-194.el5-i686]# uname -a Linux localhost.localdomain 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:43 EDT 2010 i686 i686 i386 GNU/Linux [root@localhost symsets-2.6.18-194.el5]# grep -nri "napi" * rhel5_net_u5.b8ff6a828f711a5e1b1c4fca38d2e14160a7edd3:1:0x9206f70a napi_gro_receive net/built-in.o *** NOTE ***: No napi_gro_flush in the symsets (5.5 server base kernel-devel package) The upshot of this is that our package cannot install because its requirements will *never* be met. It *should* have been met by the rhel5_net_u5 group, but that group does not include this symbol. In 5.4, not of the napi symbols are included... In 5.5, napi_gro_receive is, but none of the other symbols are. Version-Release number of selected component (if applicable): 5.4 Server and 5.5 Server How reproducible: 100% reproducible Steps to Reproduce: 1. Build a module from source package that uses a symbol supported by the current kernel, but not in its symset file. The napi symbols listed above are currently the only ones I know about. Actual results: rpm -Uvh the resulting binary kmod package. You will see a require lines as above: ksym(napi_gro_flush) = db2247bc Expected results: It *should* have fallen into one of the kernel symbol groups and look more like the following: kernel(rhel5_net_core_u4) = 833236420370073f165b26ec2d5d17ae7b10024a Additional info: Contact me directly at timothy.renner if you require our source package to test against. It's not my call to give away source, but I'll get in touch with the appropriate management.
Hi Timothy, Thanks for the bug report. This is intended behavior in RHEL5. If a symbol is not on the "whitelist" for a given kernel, then it is not generally supported for use by third party drivers. There is a means to work around this, but I would like to know why you need to use these symbols first. Which driver is this? Jon.
This is for the VMware vmxnet3 driver. I'll have to get in touch with our driver developers to find out why we want to use this symbol, but when it's available, it's used (So on RHEL 5.0 this issue doesn't crop up, since the symbol isn't available in that kernel). If it hasn't been whitelisted, I'm assuming there's a good reason for that. I'd like to know why, so I can pass it on. Also, just for my reference, how do you get around this issue? -Tim
Update from our driver guys: "I don't have the history here, but presumably, gro is supported in 5.4 and since we see NETIF_F_GRO being defined, we try to use it. GRO is nice, and we probably would want it...... It will still be used for rhel6, because the later kernel versions (>2.6.30), we always use napi." So we use the symbols because NETIF_F_GRO is defined. Existence of that symbol implies the existence of the new NAPI APIs and from the kernel history from 5.0 -> 5.5, I assume they've been backported into 2.6.18. I assuming these symbols will be whitelisted for RHEL 6? Were they deemed not ready for production in RHEL 5, even though the API has been exposed?
(In reply to comment #1) > Hi Timothy, > > Thanks for the bug report. This is intended behavior in RHEL5. If a symbol is > not on the "whitelist" for a given kernel, then it is not generally supported > for use by third party drivers. There is a means to work around this, but I > would like to know why you need to use these symbols first. Which driver is > this? > > Jon. Hi Jon. Could you please let us know what that workaround is? We're a bit stuck at the moment, because - even in the best-case scenario where RH decides to whitelist the napi symbols in RHEL 5.6 - we still would not be able to recommend our vmxnet3 driver package that uses the driver update program to customers running RHEL 5 since that package won't install without --nodeps on RHEL 5.3, 5.4, and 5.5.
Hi again Jon. It's been about three weeks since I asked for an update. Can I please get one? We're approaching an internal deadline quickly, and this is a blocker issue for us. Can we please get an idea of what the workaround is that you mentioned in comment 1, and understand what we or Red Hat needs to do to get this fixed for 5.6 and beyond?
Never mind. We resolved this internally at VMware by changing our vmxnet3 source code to not use the napi symbols for 2.6.18-* kernels. Jon, feel free to close this bug.