[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230717114307.46124-1-aspsk@isovalent.com>
Date: Mon, 17 Jul 2023 11:43:05 +0000
From: Anton Protopopov <aspsk@...valent.com>
To: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>,
Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...gle.com>,
Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
Brian Vazquez <brianvv@...gle.com>,
Hou Tao <houtao1@...wei.com>, Joe Stringer <joe@...valent.com>,
bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: Anton Protopopov <aspsk@...valent.com>
Subject: [PATCH bpf-next 0/2] fix setting return values for htab batch ops and docs
This is a small follow up to the conversation with Hou in the following
thread:
https://lore.kernel.org/bpf/20230705160139.19967-1-aspsk@isovalent.com/T/#u
Namely, the conversation was about that comments in <linux/bpf.h>
describing the return values from the batch operations are not 100%
obvious. I tried to make comments more clear. While doing this I also
found that this is better to patch how __htab_map_lookup_and_delete_batch
sets return values: the output parameter count could be set to non-zero in
case of error, which may confuse some userspace apps (as errno && non-zero
counter is considered a partially successful operation for batch ops).
Anton Protopopov (2):
bpf: fix setting return values for htab batch ops
bpf: update uapi/linux/bpf.h docs on the batch map ops
include/uapi/linux/bpf.h | 22 ++++++++++++----------
kernel/bpf/hashtab.c | 14 +++++++-------
2 files changed, 19 insertions(+), 17 deletions(-)
--
2.34.1
Powered by blists - more mailing lists