On 12/01/2016 06:58 AM, Don Zickus wrote: > On Thu, Dec 01, 2016 at 07:53:06AM -0600, Justin Forbes wrote: >> On Wed, Nov 30, 2016 at 8:03 PM, Don Zickus <dzickus@xxxxxxxxxx> wrote: >> >>> On Wed, Nov 30, 2016 at 04:25:30PM -0800, Laura Abbott wrote: >>>>> I don't think it would be a bad idea to enable in rawhide and see how >>> it works out, from there it will trickle down as the stable releases get >>> rebased. While turning it on in theory shouldn't create a problem. I >>> honestly don't get warm fuzzies making such a change without at least some >>> time testing in rawhide. We are just a week or two away from 4.9 final now, >>> so it isn't a huge delay. The changes being proposed upstream are not even >>> in next yet, so it has some time to be shaken out before it would ever see >>> a stable release, though the feature would need to be enabled in rawhide >>> for testing as that happens. >>>>> >>>>> Justin >>>>> >>>>> >>>> >>>> I'm not opposed to turning it on but I'm a little bit wary >>>> of this causing unexpected problems for users. From >>>> experience, how likely is it that a module passes the version >>>> checks but something else has changed such that it no longer >>>> works? Even if we can't officially support 3rd party modules, >>>> I'd like to not make it too much worse within reason. >>> >>> Hi Laura, >>> >>> Thanks for the feedback! >>> >>> That can always be the case, static inlines for example. But RHEL has been >>> relying on this since RHEL-5 with many 3rd party drivers. Various fixes >>> have gone in to the genksyms tool to make this interface fairly reliable. >>> >> >> RHEL relying on this without major issues is very different than Fedora >> relying on it. Fedora 23 which will EOL this month released with a 4.2 >> kernel and is currently using 4.8.10. > > Hi Justin, > > In that scenario, I would fully expect lots of symbols to break after each > major kernel version release. As a result a driver would fail to load and > would need to be rebuilt. No different than today. > > I don't expect Fedora to change any process or policy here. I was just > trying to point out that the MODVERSIONS technology works well (despite the > upstream thread which broke things when enabling EXPORT_SYMBOL in asm > files due to a bad binutil version). :-) > > Based on the upstream thread, it seems there is widespread frustration with > guaranteeing correct module load with different kernel versions. > MODVERSIONS is pretty good today, but folks want better. Red Hat would like > to help promote better technology here as kabi is something of a value add > on RHEL. > > It is easier to do that if we can sync up some of RHEL's process with Fedora > to aid in flushing out issues. That is really my main motivation here. > > We can then use RH's internal testing and tooling to help verify things. > > I believe it should have zero impact on Fedora. The upstream discussion is > now resolved for 4.9 if I understand things correctly. But feel free to > wait until 4.9 is actually released to make sure MODVERSIONS is no longer > depending on BROKEN. > > > > In case you want to understand the technology a little bit better. Today in > Fedora, module loading is based on a version string check. If the module's > version string matches the kernel's string, it will load. No other sanity > check. So if a kernel is modified but the version string isn't updated, bad > things may happen. > > MODVERSIONS takes a checksum of the _whole_ path of an EXPORT_SYMBOL and its > parameters, recursively diving through structs until it gets to the very > basic types of int, char, void, etc.. Sometimes 100 levels deep. This is > done by preprocessing the .c file into a .i fisrt. Once that extremely long > string is created, it is checksummed and stored in the .ko as the CRC. > > Any out-of-tree module compiled has to go through the same steps and uses > the crc symbols from Modules.symvers as its dependency. > > Upon module loading, if the CRCs don't match the module is blocked. If they > do match, it implies the structs, the offsets, the variable names, > everything has not changed for that EXPORT_SYMBOL (ignoring code use of > those struct elements). That is a pretty decent sanity check that the > driver should work on that kernel version. Nothing is 100%, I get that, but > with our experience on RHEL (and all the hairy rebased subsystems we do), it > has worked pretty well. > > If Fedora continues to promote DKMS and akmod, then no one has to worry > about this issue as those drivers will get stuck in extras/ and only be > available to that kernel. :-) Thanks for the explanation. Even if RHEL uses a much smaller subset of modules, it's good to hear that there haven't been too many problems. I'm okay with this being turned on for rawhide 4.10 or when it's declared stable enough. I really don't want to turn this on in one of the stable releases before it's had at least some time to sit in rawhide, as Josh said. As part of turning this on, I'd like a write up sent to fedora-devel with an explanation of what to expect (Probably nothing but please report bugs). > > > Cheers, > Don > Thanks, Laura _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
