All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Karl Mehltretter <kmehltretter@gmail.com>
Cc: "Paul Walmsley" <pjw@kernel.org>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Björn Töpel" <bjorn@kernel.org>,
	linux-riscv@lists.infradead.org, bpf@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: mm: Pre-allocate module page tables for execmem
Date: Thu, 15 Oct 2026 11:16:11 +0300	[thread overview]
Message-ID: <atCLy-3RZbf3fGRp@kernel.org> (raw)
In-Reply-To: <20261015033643.84972-1-kmehltretter@gmail.com>

On Thu, Oct 15, 2026 at 05:36:43AM +0200, Karl Mehltretter wrote:
> RV64 pre-allocates page-table levels for late kernel mappings. The module
> range is guarded by CONFIG_MODULES, although execmem can use it without
> modules.
> 
> With CONFIG_BPF_JIT=y and CONFIG_MODULES=n, execmem adds a mapping to
> init_mm while the current process retains an empty PGD entry. Initializing
> a BPF program pack then faults:
> 
>   Unable to handle kernel paging request ...
>   [ffffffff78000000] pgd=0000000000000000
>   ...
>   bpf_jit_fill_hole_with_zero
>   bpf_prog_pack_alloc
> 
> Use CONFIG_EXECMEM for the module-range pre-allocation, as powerpc does
> for its execmem page-table setup. Both CONFIG_MODULES and CONFIG_BPF_JIT
> select it.

I think the commit message should mention that BPF_JIT_REGION is inside
MODULES region.
 
> Fixes: 2c9e5d4a0082 ("bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES of")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
> 
> Notes:
>     Tested on a BeagleV Ahead with matched LLVM 18.1.3 builds based on
>     v7.3-rc7:
>     
>     - unpatched: a native XDP attach triggered the Oops above
>     - patched: native XDP attach and detach completed without an Oops
>
>  arch/riscv/mm/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index fb37b0b67efe..d92342c162e2 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -1437,7 +1437,7 @@ static void __init preallocate_pgd_pages_range(unsigned long start, unsigned lon
>  void __init pgtable_cache_init(void)
>  {
>  	preallocate_pgd_pages_range(VMALLOC_START, VMALLOC_END, "vmalloc");
> -	if (IS_ENABLED(CONFIG_MODULES))
> +	if (IS_ENABLED(CONFIG_EXECMEM))
>  		preallocate_pgd_pages_range(MODULES_VADDR, MODULES_END, "bpf/modules");
>  	if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG)) {
>  		preallocate_pgd_pages_range(VMEMMAP_START, VMEMMAP_END, "vmemmap");
> -- 
> 2.43.0
> 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Karl Mehltretter <kmehltretter@gmail.com>
Cc: "Paul Walmsley" <pjw@kernel.org>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Björn Töpel" <bjorn@kernel.org>,
	linux-riscv@lists.infradead.org, bpf@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: mm: Pre-allocate module page tables for execmem
Date: Thu, 15 Oct 2026 11:16:11 +0300	[thread overview]
Message-ID: <atCLy-3RZbf3fGRp@kernel.org> (raw)
In-Reply-To: <20261015033643.84972-1-kmehltretter@gmail.com>

On Thu, Oct 15, 2026 at 05:36:43AM +0200, Karl Mehltretter wrote:
> RV64 pre-allocates page-table levels for late kernel mappings. The module
> range is guarded by CONFIG_MODULES, although execmem can use it without
> modules.
> 
> With CONFIG_BPF_JIT=y and CONFIG_MODULES=n, execmem adds a mapping to
> init_mm while the current process retains an empty PGD entry. Initializing
> a BPF program pack then faults:
> 
>   Unable to handle kernel paging request ...
>   [ffffffff78000000] pgd=0000000000000000
>   ...
>   bpf_jit_fill_hole_with_zero
>   bpf_prog_pack_alloc
> 
> Use CONFIG_EXECMEM for the module-range pre-allocation, as powerpc does
> for its execmem page-table setup. Both CONFIG_MODULES and CONFIG_BPF_JIT
> select it.

I think the commit message should mention that BPF_JIT_REGION is inside
MODULES region.
 
> Fixes: 2c9e5d4a0082 ("bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES of")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
> 
> Notes:
>     Tested on a BeagleV Ahead with matched LLVM 18.1.3 builds based on
>     v7.3-rc7:
>     
>     - unpatched: a native XDP attach triggered the Oops above
>     - patched: native XDP attach and detach completed without an Oops
>
>  arch/riscv/mm/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index fb37b0b67efe..d92342c162e2 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -1437,7 +1437,7 @@ static void __init preallocate_pgd_pages_range(unsigned long start, unsigned lon
>  void __init pgtable_cache_init(void)
>  {
>  	preallocate_pgd_pages_range(VMALLOC_START, VMALLOC_END, "vmalloc");
> -	if (IS_ENABLED(CONFIG_MODULES))
> +	if (IS_ENABLED(CONFIG_EXECMEM))
>  		preallocate_pgd_pages_range(MODULES_VADDR, MODULES_END, "bpf/modules");
>  	if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG)) {
>  		preallocate_pgd_pages_range(VMEMMAP_START, VMEMMAP_END, "vmemmap");
> -- 
> 2.43.0
> 

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2026-10-15  8:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15  3:36 [PATCH] riscv: mm: Pre-allocate module page tables for execmem Karl Mehltretter
2026-10-15  3:36 ` Karl Mehltretter
2026-10-15  8:16 ` Mike Rapoport [this message]
2026-10-15  8:16   ` Mike Rapoport
2026-10-15 16:19 ` Björn Töpel
2026-10-15 16:19   ` Björn Töpel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=atCLy-3RZbf3fGRp@kernel.org \
    --to=rppt@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=bjorn@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kmehltretter@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mcgrof@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.