From: Martin KaFai Lau <martin.lau@linux.dev>
To: bpf@vger.kernel.org
Cc: 'Alexei Starovoitov ' <ast@kernel.org>,
'Andrii Nakryiko ' <andrii@kernel.org>,
'Daniel Borkmann ' <daniel@iogearbox.net>,
'Song Liu ' <songliubraving@meta.com>,
kernel-team@meta.com
Subject: [PATCH bpf-next 4/9] bpf: Avoid taking spinlock in bpf_task_storage_get if potential deadlock is detected
Date: Tue, 25 Oct 2022 11:45:19 -0700 [thread overview]
Message-ID: <20221025184524.3526117-5-martin.lau@linux.dev> (raw)
In-Reply-To: <20221025184524.3526117-1-martin.lau@linux.dev>
From: Martin KaFai Lau <martin.lau@kernel.org>
bpf_task_storage_get() does a lookup and optionally inserts
new data if BPF_LOCAL_STORAGE_GET_F_CREATE is present.
During lookup, it will cache the lookup result and caching requires to
acquire a spinlock. When potential deadlock is detected (by the
bpf_task_storage_busy pcpu-counter added in
commit bc235cdb423a ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]")),
the current behavior is returning NULL immediately to avoid deadlock. It is
too pessimistic. This patch will go ahead to do a lookup (which is a
lockless operation) but it will avoid caching it in order to avoid
acquiring the spinlock.
When lookup fails to find the data and BPF_LOCAL_STORAGE_GET_F_CREATE
is set, an insertion is needed and this requires acquiring a spinlock.
This patch will still return NULL when a potential deadlock is detected.
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
---
kernel/bpf/bpf_local_storage.c | 1 +
kernel/bpf/bpf_task_storage.c | 15 ++++++++-------
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/kernel/bpf/bpf_local_storage.c b/kernel/bpf/bpf_local_storage.c
index 9dc6de1cf185..781d14167140 100644
--- a/kernel/bpf/bpf_local_storage.c
+++ b/kernel/bpf/bpf_local_storage.c
@@ -242,6 +242,7 @@ void bpf_selem_unlink(struct bpf_local_storage_elem *selem, bool use_trace_rcu)
__bpf_selem_unlink_storage(selem, use_trace_rcu);
}
+/* If cacheit_lockit is false, this lookup function is lockless */
struct bpf_local_storage_data *
bpf_local_storage_lookup(struct bpf_local_storage *local_storage,
struct bpf_local_storage_map *smap,
diff --git a/kernel/bpf/bpf_task_storage.c b/kernel/bpf/bpf_task_storage.c
index 2726435e3eda..bc52bc8b59f7 100644
--- a/kernel/bpf/bpf_task_storage.c
+++ b/kernel/bpf/bpf_task_storage.c
@@ -230,17 +230,17 @@ static int bpf_pid_task_storage_delete_elem(struct bpf_map *map, void *key)
/* Called by bpf_task_storage_get*() helpers */
static void *__bpf_task_storage_get(struct bpf_map *map,
struct task_struct *task, void *value,
- u64 flags, gfp_t gfp_flags)
+ u64 flags, gfp_t gfp_flags, bool nobusy)
{
struct bpf_local_storage_data *sdata;
- sdata = task_storage_lookup(task, map, true);
+ sdata = task_storage_lookup(task, map, nobusy);
if (sdata)
return sdata->data;
/* only allocate new storage, when the task is refcounted */
if (refcount_read(&task->usage) &&
- (flags & BPF_LOCAL_STORAGE_GET_F_CREATE)) {
+ (flags & BPF_LOCAL_STORAGE_GET_F_CREATE) && nobusy) {
sdata = bpf_local_storage_update(
task, (struct bpf_local_storage_map *)map, value,
BPF_NOEXIST, gfp_flags);
@@ -254,17 +254,18 @@ static void *__bpf_task_storage_get(struct bpf_map *map,
BPF_CALL_5(bpf_task_storage_get_recur, struct bpf_map *, map, struct task_struct *,
task, void *, value, u64, flags, gfp_t, gfp_flags)
{
+ bool nobusy;
void *data;
WARN_ON_ONCE(!bpf_rcu_lock_held());
if (flags & ~BPF_LOCAL_STORAGE_GET_F_CREATE || !task)
return (unsigned long)NULL;
- if (!bpf_task_storage_trylock())
- return (unsigned long)NULL;
+ nobusy = bpf_task_storage_trylock();
data = __bpf_task_storage_get(map, task, value, flags,
- gfp_flags);
- bpf_task_storage_unlock();
+ gfp_flags, nobusy);
+ if (nobusy)
+ bpf_task_storage_unlock();
return (unsigned long)data;
}
--
2.30.2
next prev parent reply other threads:[~2022-10-25 18:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 18:45 [PATCH bpf-next 0/9] bpf: Avoid unnecessary deadlock detection and failure in task storage Martin KaFai Lau
2022-10-25 18:45 ` [PATCH bpf-next 1/9] bpf: Remove prog->active check for bpf_lsm and bpf_iter Martin KaFai Lau
2022-10-25 18:45 ` [PATCH bpf-next 2/9] bpf: Append _recur naming to the bpf_task_storage helper proto Martin KaFai Lau
2022-10-25 18:45 ` [PATCH bpf-next 3/9] bpf: Refactor the core bpf_task_storage_get logic into a new function Martin KaFai Lau
2022-10-25 18:45 ` Martin KaFai Lau [this message]
2022-10-25 18:45 ` [PATCH bpf-next 5/9] bpf: Add new bpf_task_storage_get proto with no deadlock detection Martin KaFai Lau
2022-10-25 18:45 ` [PATCH bpf-next 6/9] bpf: bpf_task_storage_delete_recur does lookup first before the deadlock check Martin KaFai Lau
2022-10-25 18:45 ` [PATCH bpf-next 7/9] bpf: Add new bpf_task_storage_delete proto with no deadlock detection Martin KaFai Lau
2022-10-25 18:45 ` [PATCH bpf-next 8/9] selftests/bpf: Ensure no task storage failure for bpf_lsm.s prog due to " Martin KaFai Lau
2022-10-25 18:45 ` [PATCH bpf-next 9/9] selftests/bpf: Tracing prog can still do lookup under busy lock Martin KaFai Lau
2022-10-26 6:20 ` [PATCH bpf-next 0/9] bpf: Avoid unnecessary deadlock detection and failure in task storage patchwork-bot+netdevbpf
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=20221025184524.3526117-5-martin.lau@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@meta.com \
--cc=songliubraving@meta.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.