From: Al Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
Cc: Juntong Deng <juntong.deng@outlook.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com,
andrii@kernel.org, martin.lau@linux.dev, eddyz87@gmail.com,
song@kernel.org, yonghong.song@linux.dev, kpsingh@kernel.org,
sdf@fomichev.me, haoluo@google.com, jolsa@kernel.org,
memxor@gmail.com, snorcht@gmail.com, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH bpf-next v9 1/5] bpf: Introduce task_file open-coded iterator kfuncs
Date: Fri, 31 Jan 2025 05:52:27 +0000 [thread overview]
Message-ID: <20250131055227.GU1977892@ZenIV> (raw)
In-Reply-To: <20250130-hautklinik-quizsendung-d36d8146bc7b@brauner>
On Thu, Jan 30, 2025 at 05:04:42PM +0100, Christian Brauner wrote:
> I'm also not at all swayed by the fact that this is coming out of an
> effort to move CRIU into bpf just to make things easier. Not a selling
> point as we do have CRIU and I don't think we need to now put more CRIU
> related stuff into the kernel.
>
> So this will not get an ACK from me. I'm putting Al and Linus here as
> well as they might have opinions on this and might disagree with me.
Strongly seconded. While we are at it, one thing I really hate about
BPF access to descriptor tables is the idiotic idea of using descriptor
table as private data structure. Sure, when talking to userland it's
perfectly fine to stash your object into descriptor table and use
descriptors for marshalling that. Doing that kernel-side is inherently
racy, especially if you end up assuming that underlying object won't
go away until your skel_closenz() - or that it will go away as soon
as that thing is called. And judging by experience with regular
kernel code, that's an assumption that gets made again and again;
see anon_inode_getfile() callers that used to be anon_inode_getfd() -
a lot of those appeared while whacking those moles...
next prev parent reply other threads:[~2025-01-31 5:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 23:44 [PATCH bpf-next v9 0/5] bpf: Add open-coded style process file iterator and bpf_fget_task() kfunc Juntong Deng
2025-01-27 23:46 ` [PATCH bpf-next v9 1/5] bpf: Introduce task_file open-coded iterator kfuncs Juntong Deng
2025-01-30 2:35 ` Alexei Starovoitov
2025-01-30 16:04 ` Christian Brauner
2025-01-30 16:35 ` Linus Torvalds
2025-01-31 5:52 ` Al Viro [this message]
2025-01-27 23:46 ` [PATCH bpf-next v9 2/5] selftests/bpf: Add tests for open-coded style process file iterator Juntong Deng
2025-01-27 23:46 ` [PATCH bpf-next v9 3/5] bpf: Add bpf_fget_task() kfunc Juntong Deng
2025-01-27 23:46 ` [PATCH bpf-next v9 4/5] bpf: Make fs kfuncs available for SYSCALL program type Juntong Deng
2025-01-30 15:32 ` Christian Brauner
2025-01-27 23:46 ` [PATCH bpf-next v9 5/5] selftests/bpf: Add tests for bpf_fget_task() kfunc Juntong Deng
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=20250131055227.GU1977892@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=juntong.deng@outlook.com \
--cc=kpsingh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=sdf@fomichev.me \
--cc=snorcht@gmail.com \
--cc=song@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=yonghong.song@linux.dev \
/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