From: John Fastabend <john.fastabend@gmail.com>
To: Kui-Feng Lee <sinquersw@gmail.com>, Ma Ke <make_ruc2021@163.com>,
john.fastabend@gmail.com, jakub@cloudflare.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH] bpf, sockmap: fix deadlocks in the sockhash and sockmap
Date: Wed, 20 Sep 2023 11:07:06 -0700 [thread overview]
Message-ID: <650b34ca2b41c_4e8122080@john.notmuch> (raw)
In-Reply-To: <dc84f39f-5b13-4a7d-a26c-598227fd9a42@gmail.com>
Kui-Feng Lee wrote:
>
>
> On 9/18/23 02:36, Ma Ke wrote:
> > It seems that elements in sockhash are rarely actively
> > deleted by users or ebpf program. Therefore, we do not
We never delete them in our usage. I think soon we will have
support to run BPF programs without a map at all removing these
concerns for many use cases.
> > pay much attention to their deletion. Compared with hash
> > maps, sockhash only provides spin_lock_bh protection.
> > This causes it to appear to have self-locking behavior
> > in the interrupt context, as CVE-2023-0160 points out.
CVE is a bit exagerrated in my opinion. I'm not sure why
anyone would delete an element from interrupt context. But,
OK if someone wrote such a thing we shouldn't lock up.
> >
> > Signed-off-by: Ma Ke <make_ruc2021@163.com>
> > ---
> > net/core/sock_map.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/core/sock_map.c b/net/core/sock_map.c
> > index cb11750b1df5..1302d484e769 100644
> > --- a/net/core/sock_map.c
> > +++ b/net/core/sock_map.c
> > @@ -928,11 +928,12 @@ static long sock_hash_delete_elem(struct bpf_map *map, void *key)
> > struct bpf_shtab_bucket *bucket;
> > struct bpf_shtab_elem *elem;
> > int ret = -ENOENT;
> > + unsigned long flags;
>
> Keep reverse xmas tree ordering?
>
> >
> > hash = sock_hash_bucket_hash(key, key_size);
> > bucket = sock_hash_select_bucket(htab, hash);
> >
> > - spin_lock_bh(&bucket->lock);
> > + spin_lock_irqsave(&bucket->lock, flags);
The hashtab code htab_lock_bucket also does a preempt_disable()
followed by raw_spin_lock_irqsave(). Do we need this as well
to handle the PREEMPT_CONFIG cases.
I'll also take a look, but figured I would post the question given
I wont likely get time to check until tonight/tomorrow.
Also converting to irqsave before ran into syzbot crash wont this do the
same?
> > elem = sock_hash_lookup_elem_raw(&bucket->head, hash, key, key_size);
> > if (elem) {
> > hlist_del_rcu(&elem->node);
> > @@ -940,7 +941,7 @@ static long sock_hash_delete_elem(struct bpf_map *map, void *key)
> > sock_hash_free_elem(htab, elem);
> > ret = 0;
> > }
> > - spin_unlock_bh(&bucket->lock);
> > + spin_unlock_irqrestore(&bucket->lock, flags);
> > return ret;
> > }
> >
next prev parent reply other threads:[~2023-09-20 18:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 9:36 [PATCH] bpf, sockmap: fix deadlocks in the sockhash and sockmap Ma Ke
2023-09-18 18:49 ` Kui-Feng Lee
2023-09-20 18:07 ` John Fastabend [this message]
2023-09-21 1:31 ` Martin KaFai Lau
2023-09-21 4:52 ` John Fastabend
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=650b34ca2b41c_4e8122080@john.notmuch \
--to=john.fastabend@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jakub@cloudflare.com \
--cc=kuba@kernel.org \
--cc=make_ruc2021@163.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sinquersw@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).