Re: kernel segv with 2.6.31-rc6 ?

[Roland McGrath <roland@redhat.com>]

> Using ET_DYN would have made our life easier when trying to code the
> kernel module loader as well.  The basic problem is, of course, that
> this is simple on an x86, so it didn't matter that much for the initial
> implementation.  It just becomes less simple on anything else.

There are generic ways that ET_DYN is better for all, too.  
A little birdie told me it was all the fault of mips.
Anyway, water under the bridge.

> Well, since they're still making parisc machines, I assume you mean
> further back than when the production lines knocked off today?

I'm pretty sure you knew what I meant.

> So that leaves us stuck with the current implementation and still
> needing a solution for the duplicate section names?

Something like that.  Your fix makes module loading work again, so we
could just let /sys/module/*/{sections,notes}/ be missing on parisc
and see how long it takes anybody to complain, assuming you talk Rusty
out of his preference to change those error cases to refuse to load
the module.  OTOH, you said earlier that it was only some mistake that
produced multiple same-named sections to begin with, so you could just
try to fix that and then forget about it.

Finally, we could decide to really support the general case including
duplicate section names in these features.  That's really not very
hard to do, if we just completely change the interfaces for those
features.  e.g. instead of a /sys/module/*/sections directory, it
could just be a single file that contains lines of:

SHNDX 0xADDR NAME

For /sys/module/*/notes, no consumer really cares about the section
distinctions at all.  It would be easy enough just to have a single
pseudo-file that delivers all note sections concatenated together.
(In practice, there is usually only one note section at most anyway.)

Of course, such changes would be a new incompatible change to the
userland sysfs ABI, require compatibility concerns, etc.  It seems
unlikely anyone really wants to bother with all that.  It would be
more natural presentation of the info IMHO, but it hardly matters.


Thanks,
Roland