On Thu, 2016-12-01 at 12:55 +1100, Nicholas Piggin wrote:

On Wed, 30 Nov 2016 21:33:01 +0000

quoted

Ben Hutchings [off-list ref] wrote:

quoted

On Wed, 2016-11-30 at 10:40 -0800, Linus Torvalds wrote:

quoted

quoted

On Wed, Nov 30, 2016 at 10:18 AM, Nicholas Piggin [off-list ref] 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.
  

quoted

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.

quoted

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.

quoted

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