Re: [PATCH bpf-next 2/3] bpf: Add user memory access kfuncs for linux_binprm

On Tue, Aug 18, 2026 at 11:24:41AM +0300, Anastasios Papagiannis wrote:
> Thanks for the review!
> 
> > Would it be better to handle that case transparently rather than
> > requiring introducing a new kfunc / leaving that gap open for NOMMU?
> 
> > Either return an error or perform the copy from bprm->page[].
> 
> > Unless there's some reason I'm not seeing.
> 
> My understanding is that there is currently no way to use these kfuncs
> on a NOMMU system. Although CONFIG_BPF_LSM does not directly depend on
> CONFIG_MMU, as far as I can tell, no current NOMMU architecture provides
> the required support to use them. For this reason even if I write that
> code, this cannot be tested.
> 
> > It would also be better for portability across NOMMU / CONFIG_MMU
> > systems (the exisiting kfunc is never registered, so a program using it
> > would be rejected rather than able to handle the error).
> 
> As you suggested, I would propose to register those kfuncs
> unconditionally, move the ifdefs inside those kfuncs, in the case
> of NOMMU return an error (e.g. -EOPNOTSUPP) and allow the programs to
> handle those.
> 
> Does this sound reasonable?
>
Yes that does. It's a small niche anyway (I don't think a lot of people
are using BPF and NOMMU anyway, and BPF_LSM && !MMU is unsatisfiable
unless RISC-V or some other architecture gets JIT support in nommu)

And when/if (big if) it does, they wouldn't even need this kfunc and could
bpf_probe_read_kernel() bprm->page[] directly.

So an error is best. 

Justin
> Thanks,
> Anastasios