Re: Error on loading some network Kernel modules

From: Troy Benjegerdes <troy.benjegerdes@sifive.com>
To: Anup Patel <anup@brainfault.org>, Paul Walmsley <paul@pwsan.com>,
	David Abdurachmanov <david.abdurachmanov@gmail.com>
Cc: Carlos Eduardo de Paula <me@carlosedp.com>,
	Alex Ghiti <alex@ghiti.fr>,
	Vincent Chen <vincent.chen@sifive.com>,
	Romain Dolbeau <romain.dolbeau@european-processor-initiative.eu>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: Error on loading some network Kernel modules
Date: Sun, 2 Feb 2020 09:21:07 -0600	[thread overview]
Message-ID: <E675ABCB-5733-4BB3-9357-A384B7E94EAE@sifive.com> (raw)
In-Reply-To: <CAAhSdy2skCD4NEt2i7Df5VVO6T+Uz1YmeRfXLN9KTreu45Z9ng@mail.gmail.com>

Do we have a good place to put a community-supported ‘riscv-stable’ tree somewhere that we can put stuff like this we need for basic functionality so we don’t lose it again?

I also feel like there’s a need to backport some patches like this to a -stable/lts kernel series, and 4.19 seems a little old to keep maintaining..

> On Feb 2, 2020, at 8:10 AM, Anup Patel <anup@brainfault.org> wrote:
> 
> On Sat, Feb 1, 2020 at 7:30 PM Alex Ghiti <alex@ghiti.fr> wrote:
>> 
>> On 2/1/20 2:52 AM, Anup Patel wrote:
>>> On Sat, Feb 1, 2020 at 1:41 AM Aurelien Jarno <aurelien@aurel32.net> wrote:
>>>> On 2020-01-30 17:20, David Abdurachmanov wrote:
>>>>> On Thu, Jan 30, 2020 at 4:00 AM Paul Walmsley <paul@pwsan.com> wrote:
>>>>>> On Tue, 28 Jan 2020, Carlos Eduardo de Paula wrote:
>>>>>> 
>>>>>>> I currently run stock Kernel 5.5.0-rc7 on my Unleashed board with most
>>>>>>> network features I need baked into the kernel instead of modules.
>>>>>>> 
>>>>>>> I tried building a kernel with these network features as modules but
>>>>>>> when loading some of them I got this error:
>>>>>>> 
>>>>>>> root@unleashed:~# uname -a
>>>>>>> Linux unleashed 5.5.0-rc7-dirty #4 SMP Fri Jan 24 18:16:43 -02 2020
>>>>>>> riscv64 GNU/Linux
>>>>>>> 
>>>>>>> root@unleashed:~# modprobe br_netfilter
>>>>>>> [  139.290533] br_netfilter: target ffffffe0000422d8 can not be
>>>>>>> addressed by the 32-bit offset from PC = 000000003dfd6deb
>>>>>> This is a known issue:
>>>>>> 
>>>>>> https://lore.kernel.org/linux-riscv/1572281840733.3517@european-processor-initiative.eu/
>>>>>> 
>>>>>> https://lore.kernel.org/linux-riscv/20191029105055.GA20736@aurel32.net/#r
>>>>>> 
>>>>>> Vincent is looking into it and I expect there will be a fix soon.
>>>>>> 
>>>>> Is this patch solving the problem?
>>>>> 
>>>>> https://github.com/bjoto/linux/commit/8a56d1c8e8e91c1bc3893946d52b9217c96e1589
>>>> I have just tried that patch on top of a 5.4.13 kernel, and I confirm it
>>>> fixes the issue. Thanks!
>>> I guess this patch was lost over time.
>>> 
>>> First of all we need to rebase this patch on latest kernel.
>>> 
>>> The MODULES_xyz defines are totally redundant and create
>>> confusion because with these defines it seems we are creating
>>> separate virtual memory region for modules which is not true.
>>> In fact, the patch only tries to ensure that modules are allocated
>>> from the end-of VMALLOC region.
>>> 
>>> I suggest to drop all MODULES_xyz defines and implement
>>> module_alloc() as follows:
>>> 
>>> void *module_alloc(unsigned long size)
>>> {
>>> return __vmalloc_node_range(size, 1, VMALLOC_END - SZ_128M,
>>> VMALLOC_END, GFP_KERNEL,
>>> PAGE_KERNEL_EXEC, 0,
>>> NUMA_NO_NODE,
>>> __builtin_return_address(0));
>>> }
>> 
>> 
>> Why restrict to 128M whereas we have 2GB offset available to the end of
>> the kernel ?
>> 
>> I think the cleanest solution is to use the following range [&_end - 2 *
>> SZ_1G; VMALLOC_END].
> 
> I agree we should not restrict to just SZ_128M.
> 
> You can go ahead and send a patch this (if you want).
> 
> Regards,
> Anup