On Thu, Dec 01, 2016 at 08:49:24AM -0800, Laura Abbott wrote:
> 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 <dzic...@redhat.com> 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
I guess that write up would fall on me. :-) Sure. Once everything is declared
stable, let me know and we can work together to craft something.
> > Cheers,
> > Don
> kernel mailing list -- email@example.com
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
kernel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org