From: Daniel Bokmann <darkstar@linux.home>
To: sdf@google.com
Cc: Hou Tao <houtao@huaweicloud.com>,
bpf@vger.kernel.org, Yonghong Song <yhs@fb.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Andrii Nakryiko <andrii@kernel.org>, Song Liu <song@kernel.org>,
Hao Luo <haoluo@google.com>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
KP Singh <kpsingh@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Xu Kuohai <xukuohai@huawei.com>,
houtao1@huawei.com
Subject: Re: [PATCH bpf-next v2] bpf: Pass map file to .map_update_batch directly
Date: Mon, 14 Nov 2022 18:49:44 +0100 [thread overview]
Message-ID: <20221114174944.GA29631@linux.home> (raw)
In-Reply-To: <Y26JtknJKjnD+dsu@google.com>
On Fri, Nov 11, 2022 at 09:43:18AM -0800, sdf@google.com wrote:
> On 11/11, Hou Tao wrote:
> > From: Hou Tao <houtao1@huawei.com>
>
> > Currently bpf_map_do_batch() first invokes fdget(batch.map_fd) to get
> > the target map file, then it invokes generic_map_update_batch() to do
> > batch update. generic_map_update_batch() will get the target map file
> > by using fdget(batch.map_fd) again and pass it to
> > bpf_map_update_value().
>
> > The problem is map file returned by the second fdget() may be NULL or a
> > totally different file compared by map file in bpf_map_do_batch(). The
> > reason is that the first fdget() only guarantees the liveness of struct
> > file instead of file descriptor and the file description may be released
> > by concurrent close() through pick_file().
>
> > It doesn't incur any problem as for now, because maps with batch update
> > support don't use map file in .map_fd_get_ptr() ops. But it is better to
> > fix the access of a potentially invalid map file.
Right, that's mainly for the perf RB map ...
> > using __bpf_map_get() again in generic_map_update_batch() can not fix
> > the problem, because batch.map_fd may be closed and reopened, and the
> > returned map file may be different with map file got in
> > bpf_map_do_batch(), so just passing the map file directly to
> > .map_update_batch() in bpf_map_do_batch().
>
> > Signed-off-by: Hou Tao <houtao1@huawei.com>
>
> Acked-by: Stanislav Fomichev <sdf@google.com>
> [..]
>
> > +#define BPF_DO_BATCH_WITH_FILE(fn) \
> > + do { \
> > + if (!fn) { \
> > + err = -ENOTSUPP; \
> > + goto err_put; \
> > + } \
> > + err = fn(map, f.file, attr, uattr); \
> > + } while (0)
> > +
>
> nit: probably not worth defining this for a single user? but not sure
> it matters..
Yeah, just the BPF_DO_BATCH could be used but extended via __VA_ARGS__.
Thanks,
Daniel
next prev parent reply other threads:[~2022-11-14 17:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-11 8:07 [PATCH bpf-next v2] bpf: Pass map file to .map_update_batch directly Hou Tao
2022-11-11 17:43 ` sdf
2022-11-14 17:49 ` Daniel Bokmann [this message]
2022-11-15 11:18 ` Hou Tao
2022-11-11 23:02 ` Yonghong Song
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=20221114174944.GA29631@linux.home \
--to=darkstar@linux.home \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=houtao1@huawei.com \
--cc=houtao@huaweicloud.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=xukuohai@huawei.com \
--cc=yhs@fb.com \
/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.