From: Hou Tao <houtao1@huawei.com>
To: <xiangxia.m.yue@gmail.com>, <bpf@vger.kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>
Subject: Re: [bpf-next 1/2] bpf: hash map, avoid deadlock with suitable hash mask
Date: Fri, 16 Dec 2022 18:15:18 +0800 [thread overview]
Message-ID: <2e2dc326-69ad-1228-c425-357dcdb6bfcd@huawei.com> (raw)
In-Reply-To: <20221214103857.69082-1-xiangxia.m.yue@gmail.com>
Hi,
On 12/14/2022 6:38 PM, xiangxia.m.yue@gmail.com wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> The deadlock still may occur while accessed in NMI and non-NMI
> context. Because in NMI, we still may access the same bucket but with
> different map_locked index.
>
> For example, on the same CPU, .max_entries = 2, we update the hash map,
> with key = 4, while running bpf prog in NMI nmi_handle(), to update
> hash map with key = 20, so it will have the same bucket index but have
> different map_locked index.
>
> To fix this issue, using min mask to hash again.
>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Andrii Nakryiko <andrii@kernel.org>
> Cc: Martin KaFai Lau <martin.lau@linux.dev>
> Cc: Song Liu <song@kernel.org>
> Cc: Yonghong Song <yhs@fb.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Cc: KP Singh <kpsingh@kernel.org>
> Cc: Stanislav Fomichev <sdf@google.com>
> Cc: Hao Luo <haoluo@google.com>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Hou Tao <houtao1@huawei.com>
> ---
> kernel/bpf/hashtab.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 5aa2b5525f79..8b25036a8690 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -152,7 +152,7 @@ static inline int htab_lock_bucket(const struct bpf_htab *htab,
> {
> unsigned long flags;
>
> - hash = hash & HASHTAB_MAP_LOCK_MASK;
> + hash = hash & min(HASHTAB_MAP_LOCK_MASK, htab->n_buckets -1);
There is warning for kernel test robot and it seems that min_t(...) is required
here.
Otherwise, this patch looks good to me, so:
Acked-by: Hou Tao <houtao1@huawei.com>
>
> preempt_disable();
> if (unlikely(__this_cpu_inc_return(*(htab->map_locked[hash])) != 1)) {
> @@ -171,7 +171,7 @@ static inline void htab_unlock_bucket(const struct bpf_htab *htab,
> struct bucket *b, u32 hash,
> unsigned long flags)
> {
> - hash = hash & HASHTAB_MAP_LOCK_MASK;
> + hash = hash & min(HASHTAB_MAP_LOCK_MASK, htab->n_buckets -1);
> raw_spin_unlock_irqrestore(&b->raw_lock, flags);
> __this_cpu_dec(*(htab->map_locked[hash]));
> preempt_enable();
next prev parent reply other threads:[~2022-12-16 10:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 10:38 [bpf-next 1/2] bpf: hash map, avoid deadlock with suitable hash mask xiangxia.m.yue
2022-12-14 10:38 ` [bpf-next 2/2] selftests/bpf: add test cases for htab map xiangxia.m.yue
2022-12-16 4:10 ` Yonghong Song
2022-12-16 10:36 ` Tonghao Zhang
2022-12-16 18:57 ` Yonghong Song
2022-12-16 10:41 ` Hou Tao
2022-12-16 10:45 ` Hou Tao
2022-12-16 11:01 ` Tonghao Zhang
2022-12-14 16:12 ` [bpf-next 1/2] bpf: hash map, avoid deadlock with suitable hash mask kernel test robot
2022-12-16 3:43 ` Yonghong Song
2022-12-16 10:15 ` Hou Tao [this message]
2022-12-16 10:31 ` Tonghao Zhang
2022-12-17 1:58 ` kernel test robot
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=2e2dc326-69ad-1228-c425-357dcdb6bfcd@huawei.com \
--to=houtao1@huawei.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.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=xiangxia.m.yue@gmail.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.