From: John Fastabend <john.fastabend@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>, Lorenz Bauer <lmb@cloudflare.com>
Cc: Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
duanxiongchun@bytedance.com,
Dongdong Wang <wangdongdong.6@bytedance.com>,
Jiang Wang <jiang.wang@bytedance.com>,
Cong Wang <cong.wang@bytedance.com>,
John Fastabend <john.fastabend@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Jakub Sitnicki <jakub@cloudflare.com>
Subject: Re: [Patch bpf-next v2 2/9] sock: introduce sk_prot->update_proto()
Date: Fri, 05 Mar 2021 16:27:11 -0800 [thread overview]
Message-ID: <6042cc5f4f65a_135da20824@john-XPS-13-9370.notmuch> (raw)
In-Reply-To: <CAM_iQpXXUv1FV8DQ85a2fs08JCfKHHt-fAWYbV0TTWmwUZ-K5Q@mail.gmail.com>
Cong Wang wrote:
> On Tue, Mar 2, 2021 at 10:23 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >
> > On Tue, Mar 2, 2021 at 8:22 AM Lorenz Bauer <lmb@cloudflare.com> wrote:
> > >
> > > On Tue, 2 Mar 2021 at 02:37, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > >
> > > ...
> > > > static inline void sk_psock_restore_proto(struct sock *sk,
> > > > struct sk_psock *psock)
> > > > {
> > > > sk->sk_prot->unhash = psock->saved_unhash;
> > >
> > > Not related to your patch set, but why do an extra restore of
> > > sk_prot->unhash here? At this point sk->sk_prot is one of our tcp_bpf
> > > / udp_bpf protos, so overwriting that seems wrong?
"extra"? restore_proto should only be called when the psock ref count
is zero and we need to transition back to the original socks proto
handlers. To trigger this we can simply delete a sock from the map.
In the case where we are deleting the psock overwriting the tcp_bpf
protos is exactly what we want.?
> >
> > Good catch. It seems you are right, but I need a double check. And
> > yes, it is completely unrelated to my patch, as the current code has
> > the same problem.
>
> Looking at this again. I noticed
>
> commit 4da6a196f93b1af7612340e8c1ad8ce71e18f955
> Author: John Fastabend <john.fastabend@gmail.com>
> Date: Sat Jan 11 06:11:59 2020 +0000
>
> bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop
>
> intentionally fixed a bug in kTLS with overwriting this ->unhash.
>
> I agree with you that it should not be updated for sockmap case,
> however I don't know what to do with kTLS case, it seems the bug the
> above commit fixed still exists if we just revert it.
>
> Anyway, this should be targeted for -bpf as a bug fix, so it does not
> belong to this patchset.
>
> Thanks.
Hi,
I'm missing the error case here. The restore logic happens when the refcnt
hits 0 on the psock, indicating its time to garbage collect the psock.
sk_psock_put
if (refcount_dec_and_test(&psock->refcnt))
sk_psock_drop(sk, psock);
sk_psock_restore_proto(sk, psock)
sk->sk_prot->unhash = psock->saved_unhash
When sockets are initialized via sk_psock_init() we opulate the unhash field
psock->saved_unhash = prot->unhash;
So we need to unwind this otherwise a future unhash() call would not call
the original protos unhash handler.
Care to give me some more context on what the bug is?
Thanks,
John
next prev parent reply other threads:[~2021-03-06 0:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 2:37 [Patch bpf-next v2 0/9] sockmap: introduce BPF_SK_SKB_VERDICT and support UDP Cong Wang
2021-03-02 2:37 ` [Patch bpf-next v2 1/9] sock_map: introduce BPF_SK_SKB_VERDICT Cong Wang
2021-03-02 2:37 ` [Patch bpf-next v2 2/9] sock: introduce sk_prot->update_proto() Cong Wang
2021-03-02 16:22 ` Lorenz Bauer
2021-03-02 18:23 ` Cong Wang
2021-03-03 9:35 ` Lorenz Bauer
2021-03-03 18:20 ` Cong Wang
2021-03-04 9:30 ` Lorenz Bauer
2021-03-04 23:52 ` Cong Wang
2021-03-06 0:27 ` John Fastabend [this message]
2021-03-06 0:57 ` Cong Wang
2021-03-06 1:55 ` John Fastabend
2021-03-09 17:53 ` Cong Wang
2021-03-10 6:33 ` John Fastabend
2021-03-02 2:37 ` [Patch bpf-next v2 3/9] udp: implement ->sendmsg_locked() Cong Wang
2021-03-02 2:37 ` [Patch bpf-next v2 4/9] udp: implement ->read_sock() for sockmap Cong Wang
2021-03-03 6:26 ` Yonghong Song
2021-03-02 2:37 ` [Patch bpf-next v2 5/9] udp: add ->read_sock() and ->sendmsg_locked() to ipv6 Cong Wang
2021-03-02 16:23 ` Lorenz Bauer
2021-03-02 17:59 ` Cong Wang
2021-03-02 2:37 ` [Patch bpf-next v2 6/9] skmsg: extract __tcp_bpf_recvmsg() and tcp_bpf_wait_data() Cong Wang
2021-03-02 2:37 ` [Patch bpf-next v2 7/9] udp: implement udp_bpf_recvmsg() for sockmap Cong Wang
2021-03-02 2:37 ` [Patch bpf-next v2 8/9] sock_map: update sock type checks for UDP Cong Wang
2021-03-03 6:37 ` Yonghong Song
2021-03-03 18:02 ` Cong Wang
2021-03-03 18:50 ` Yonghong Song
2021-03-02 2:37 ` [Patch bpf-next v2 9/9] selftests/bpf: add a test case for udp sockmap Cong Wang
2021-03-02 16:31 ` Lorenz Bauer
2021-03-02 18:05 ` Cong Wang
2021-03-03 10:20 ` Lorenz Bauer
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=6042cc5f4f65a_135da20824@john-XPS-13-9370.notmuch \
--to=john.fastabend@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=cong.wang@bytedance.com \
--cc=daniel@iogearbox.net \
--cc=duanxiongchun@bytedance.com \
--cc=jakub@cloudflare.com \
--cc=jiang.wang@bytedance.com \
--cc=lmb@cloudflare.com \
--cc=netdev@vger.kernel.org \
--cc=wangdongdong.6@bytedance.com \
--cc=xiyou.wangcong@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