On Thu, 2016-12-01 at 12:55 +1100, Nicholas Piggin wrote: > On Wed, 30 Nov 2016 21:33:01 +0000 > > Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote: > > > On Wed, 2016-11-30 at 10:40 -0800, Linus Torvalds wrote: > > > > On Wed, Nov 30, 2016 at 10:18 AM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > > > > > > > > Here's an initial rough hack at removing modversions. It gives an idea > > > > of the complexity we're carrying for this feature (keeping in mind most > > > > of the lines removed are generated parser). > > > > > > You definitely don't have to try to convince me. We've had many issues > > > with modversions over the years. This was just the "last drop" as far > > > as I'm concerned, we've had random odd crc generation failures due to > > > some build races too. > > > > > > > In its place I just added a simple config option to override vermagic > > > > so distros can manage it entirely themselves. > > > > > > So at least Fedora doesn't even enable CONFIG_MODVERSIONS as-is. I'm > > > _hoping_ it's just Debian that wants this, > > > > The last time I looked, RHEL and SLE did. They change the release > > string for each new kernel version, but they will copy/link old out-of- > > tree modules into the new version's "weak-updates" module subdirectory > > if the symbol versions still match. > > > > > and we'd need to get some > > > input from the Debian people whether that "control vermagic" is > > > sufficient? I suspect it isn't, but I can't come up with any simple > > > alternate model either.. > > > > Allowing the vermagic to be changed separately doesn't help us, as we > > already control the release string. If we were to change some of the > > module tools to consider vermagic then it would allow us to report the > > full version in the release string while not forcing rebuilds on every > > kernel upgrade - but that's not a pressing problem. > > Okay, but existing modversions AFAIKS does not solve your problems described > in yor your earlier mail either. Modversions hardly catches ABI breakage at > all, you can't rely on it that way. It's far more likely that some structure > size changes deep in the kernel than an exported function type signature > changes. As I understand it, genksyms incorporates the definitions of a function's parameter and return types - not just their names - and all the types they refer to, recursively. So a structure size change should change the version of all functions where the function and its caller pass that structure between them, however indirectly. It finds such indirect ABI breakage for me fairly regularly, though of course I don't know that it finds everything. > I'm not sure how you know which exports are used only by in-tree modules > and which are used out of tree, but if you know that then you can version > them manually as we said by adding _v2 in the rare case you need to change > a behaviour. That's fine for individual functions. > So I'm still having trouble understanding what modversions is giving you. Where there is a family of driver modules (e.g. foo-core, foo-pci, foo- usb), a structure change can change all exports from foo-core. That ABI is of no use to out-of-tree drivers so we don't care about keeping it stable, but we do care about preventing an accidental mismatch. > > One thing that could work for us would be: > > > > - Stricter version matching for in-tree modules (maybe some extra > > part in vermagic that is skipped for out-of-tree modules) > > - Ability to blacklist use of a symbol, or all symbols in a module, > > by out-of-tree modules > > > > where the blacklist would be a matter of distribution policy. But this > > would still require a fair amount of work by someone, and I doubt you'd > > want this upstream. > > I don't think people are adverse to carrying some upstream complexity for > ditsros. Although for this fancy blacklist case, can it just be done in > userspace? Since the kernel does the symbol lookup and version matching, I'm not sure what userland can do about it. Ben. -- Ben Hutchings A free society is one where it is safe to be unpopular. - Adlai Stevenson
Attachment:
signature.asc
Description: This is a digitally signed message part
