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
> bugs).

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

> 
> > 
> > 
> > Cheers,
> > Don
> > 
> 
> Thanks,
> Laura
> _______________________________________________
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
_______________________________________________
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Reply via email to