From: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
To: utilityemal77@gmail.com
Cc: akpm@linux-foundation.org, andrii@kernel.org, ast@kernel.org,
bpf@vger.kernel.org, brauner@kernel.org, daniel@iogearbox.net,
david@kernel.org, eddyz87@gmail.com, kpsingh@kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, matt@bobrowski.net, memxor@gmail.com,
song@kernel.org, tasos.papagiannnis@gmail.com,
viro@zeniv.linux.org.uk
Subject: Re: [PATCH bpf-next 2/3] bpf: Add user memory access kfuncs for linux_binprm
Date: Tue, 18 Aug 2026 11:24:41 +0300 [thread overview]
Message-ID: <20260818082441.4091-1-tasos.papagiannnis@gmail.com> (raw)
In-Reply-To: <any3wCj66dWbwgwT@zenbox>
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?
Thanks,
Anastasios
next prev parent reply other threads:[~2026-08-18 8:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 11:11 [PATCH bpf-next 0/3] bpf: Add user memory access kfuncs for linux_binprm Anastasios Papagiannis
2026-08-12 11:11 ` [PATCH bpf-next 1/3] mm: Add copy_remote_mm_str() Anastasios Papagiannis
2026-08-12 12:03 ` bot+bpf-ci
2026-08-12 11:11 ` [PATCH bpf-next 2/3] bpf: Add user memory access kfuncs for linux_binprm Anastasios Papagiannis
2026-08-12 12:18 ` bot+bpf-ci
2026-08-12 18:40 ` Justin Suess
2026-08-18 8:24 ` Anastasios Papagiannis [this message]
2026-08-18 21:34 ` Justin Suess
2026-08-12 11:11 ` [PATCH bpf-next 3/3] selftests/bpf: Test linux_binprm user memory kfuncs Anastasios Papagiannis
2026-08-12 12:18 ` bot+bpf-ci
2026-08-12 18:42 ` Justin Suess
-- strict thread matches above, loose matches on Subject: below --
2026-08-21 19:51 [PATCH bpf-next v2 2/3] bpf: Add user memory access kfuncs for linux_binprm Andrii Nakryiko
2026-08-24 10:49 ` [PATCH bpf-next " Anastasios Papagiannis
2026-08-24 20:01 ` Andrii Nakryiko
2026-08-31 9:25 ` Anastasios Papagiannis
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=20260818082441.4091-1-tasos.papagiannnis@gmail.com \
--to=tasos.papagiannnis@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=david@kernel.org \
--cc=eddyz87@gmail.com \
--cc=kpsingh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matt@bobrowski.net \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=utilityemal77@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox