[BUG] Module load relocation hashtable size can become huge and unallocatable
William Pierce
wgpierce17 at gmail.com
Tue Apr 1 14:00:52 PDT 2025
On 4/1/25 12:55 AM, Clément Léger wrote:
>
>
> 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
>
Hi Clément,
Thank you for checking. Yes I expect kvmalloc should also work just fine.
I can send out a patch based on that, unless someone wants to just take
the change. I'll do so in the next day or so.
- Will
>>
>> 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
>
More information about the linux-riscv
mailing list