From: John Fastabend <john.fastabend@gmail.com>
To: Eric Dumazet <edumazet@google.com>,
John Fastabend <john.fastabend@gmail.com>
Cc: jakub@cloudflare.com, daniel@iogearbox.net, lmb@isovalent.com,
cong.wang@bytedance.com, bpf@vger.kernel.org,
netdev@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
will@isovalent.com
Subject: Re: [PATCH bpf 05/11] bpf: sockmap, TCP data stall on recv before accept
Date: Tue, 21 Mar 2023 15:09:32 -0700 [thread overview]
Message-ID: <641a2b1c44846_80a24208b9@john.notmuch> (raw)
In-Reply-To: <CANn89iKFtrcbAtOZ9dppkm4AaqaQysh0r1suV9hQ5vg-zp3zZg@mail.gmail.com>
Eric Dumazet wrote:
> On Tue, Mar 21, 2023 at 2:52 PM John Fastabend <john.fastabend@gmail.com> wrote:
> >
> > A common mechanism to put a TCP socket into the sockmap is to hook the
> > BPF_SOCK_OPS_{ACTIVE_PASSIVE}_ESTABLISHED_CB event with a BPF program
> > that can map the socket info to the correct BPF verdict parser. When
> > the user adds the socket to the map the psock is created and the new
> > ops are assigned to ensure the verdict program will 'see' the sk_buffs
> > as they arrive.
> >
[...]
> > lock_sock(sk);
> > +
> > + /* We may have received data on the sk_receive_queue pre-accept and
> > + * then we can not use read_skb in this context because we haven't
> > + * assigned a sk_socket yet so have no link to the ops. The work-around
> > + * is to check the sk_receive_queue and in these cases read skbs off
> > + * queue again. The read_skb hook is not running at this point because
> > + * of lock_sock so we avoid having multiple runners in read_skb.
> > + */
> > + if (unlikely(!skb_queue_empty_lockless(&sk->sk_receive_queue))) {
>
> socket is locked here, please use skb_queue_empty() ?
>
> We shall reserve skb_queue_empty_lockless() for lockless contexts.
Yep will do thanks.
next prev parent reply other threads:[~2023-03-21 22:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-21 21:52 [PATCH bpf 00/11] bpf sockmap fixes John Fastabend
2023-03-21 21:52 ` [PATCH bpf 01/11] bpf: sockmap, pass skb ownership through read_skb John Fastabend
2023-03-21 21:52 ` [PATCH bpf 02/11] bpf: sockmap, convert schedule_work into delayed_work John Fastabend
2023-03-21 21:52 ` [PATCH bpf 03/11] bpf: sockmap, improved check for empty queue John Fastabend
2023-03-21 21:52 ` [PATCH bpf 04/11] bpf: sockmap, handle fin correctly John Fastabend
2023-03-21 21:52 ` [PATCH bpf 05/11] bpf: sockmap, TCP data stall on recv before accept John Fastabend
2023-03-21 22:07 ` Eric Dumazet
2023-03-21 22:09 ` John Fastabend [this message]
2023-03-21 21:52 ` [PATCH bpf 06/11] bpf: sockmap, wake up polling after data copy John Fastabend
2023-03-21 21:52 ` [PATCH bpf 07/11] bpf: sockmap incorrectly handling copied_seq John Fastabend
2023-03-22 3:10 ` Eric Dumazet
2023-03-22 5:39 ` John Fastabend
2023-03-21 21:52 ` [PATCH bpf 08/11] bpf: sockmap, pull socket helpers out of listen test for general use John Fastabend
2023-03-21 21:52 ` [PATCH bpf 09/11] bpf: sockmap, build helper to create connected socket pair John Fastabend
2023-03-21 21:52 ` [PATCH bpf 10/11] bpf: sockmap, test shutdown() correctly exits epoll and recv()=0 John Fastabend
2023-03-21 22:11 ` John Fastabend
2023-03-21 21:52 ` [PATCH bpf 11/11] bpf: sockmap, test FIONREAD returns correct bytes in rx buffer 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=641a2b1c44846_80a24208b9@john.notmuch \
--to=john.fastabend@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cong.wang@bytedance.com \
--cc=daniel@iogearbox.net \
--cc=edumazet@google.com \
--cc=jakub@cloudflare.com \
--cc=lmb@isovalent.com \
--cc=netdev@vger.kernel.org \
--cc=will@isovalent.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