Re: [PATCH RFC] ARM: option for loading modules into vmalloc area

From: Ard Biesheuvel
Date: Wed Nov 19 2014 - 12:59:18 EST

On 19 November 2014 18:12, Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> 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

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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at