[BUG] Module load relocation hashtable size can become huge and unallocatable

[Clément Léger]

On 01/04/2025 05:10, William Pierce wrote:
> Using vmalloc_array/vfree on the relocation_hashtable
> allows the kernel module to load just fine. I can send this
> as a patch if the fix sounds good.

Hey William,

Using vmalloc sounds reasonable since there is no need to have
physically contiguous memory.

However, there is also a new API named kvmalloc which uses kmalloc for
small sizes and vmalloc for large allocations exceeding kmalloc
capabilities, potentially leading to better performances than using
vmalloc only.

Clément

> 
> On 3/30/25 1:12 PM, William Pierce wrote:
>> Hello, I have a kernel module that requires a huge number
>> of relocations upon loading.
>>
>> On other architectures, it loads into the kernel just fine.
>> However, on riscv, while allocating memory for its relocation
>> hashtable, it ends up requesting 2097152 elements to kmalloc_array.
>>
>> Right here I've dumped the values by recompiling the kernel:
>> num_relocations: 1630985, hastable_size: 2097152
>> https://elixir.bootlin.com/linux/v6.14-rc6/source/arch/riscv/kernel/module.c#L734
>>
>> which kmalloc_array->...->___kmalloc_large_node->...->
>> __alloc_frozen_pages_noprof can't handle and returns
>> "Cannot allocate memory" on insmod.
>>
>> How would it be recommended to fix this?
>> I could imagine allocating a more discontiguous data structure
>> to track the relocations or otherwise reworking the tracking to
>> do the relocation tracking inline.
>>
>> Thank you,
>> Will Pierce
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv