[PATCH RFC] ARM: option for loading modules into vmalloc area
nicolas.pitre at linaro.org
Wed Nov 19 10:22:46 PST 2014
On Wed, 19 Nov 2014, Ard Biesheuvel wrote:
> On 19 November 2014 18:12, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> > On Wed, 19 Nov 2014, Russell King - ARM Linux wrote:
> >> On Wed, Nov 19, 2014 at 11:57:15AM -0500, Nicolas Pitre wrote:
> >> > On Wed, 19 Nov 2014, Russell King - ARM Linux wrote:
> >> > > I don't think I ever did, because its pretty much impossible to do as I
> >> > > explained in a follow up to this thread.
> >> > >
> >> > > We _used_ to do this with the userspace insmod methods, but since we got
> >> > > this kernel-side linker, it's been pretty much impossible to do without
> >> > > rewriting the module code. That's not going to happen on account of one
> >> > > quirky architecture which Linus doesn't particularly like.
> >> >
> >> > Still... We could try adding a hook in the generic module linker code
> >> > for a pre-relocation pass. Maybe only ARM would use it, but if the need
> >> > to load big modules is real then I imagine Linus could be amenable to a
> >> > compromise.
> >> So, how big a table would you allocate for the trampolines, based upon
> >> not knowing anything about the module being loaded? 4K? 8K? 64K?
> > The idea of a pre-relocation pass is to determine that. That could be
> > something similar to calling apply_relocate() twice: once to determine
> > the number of trampoline entries, and a second time to perform the
> > actual relocation.
> Well, the veneers shouldn't take more than 3 words each, right?
> ldr ip, [pc]
> bx ip
> .long symbol
You could possibly do:
ldr pc, [pc, #-4]
Or, as RMK suggested a while ago:
ldr pc, [pc, #(32 - 8)]
.long sym1, sym2, sym3, sym4, sym5, sym6, sym7, sym8
The later is much nicer on the i and d caches.
> and you would need at most one veneer per unique external symbol
> referenced by one or more R_ARM_CALL relocations. Is there no way to
> just add that to the static mem footprint as padding, and let the
> loader populate it as needed at module relocation time?
That's the actual question: how much padding do you need? Everything
converge to that very problem. We need to determine it without too much
impact on the generic module loader code.
More information about the linux-arm-kernel