From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org,
edumazet@google.com, bpf@vger.kernel.org
Subject: Re: [bpf PATCH v2 0/6] bpf: sockmap/tls fixes
Date: Mon, 8 Jul 2019 23:13:18 -0700 [thread overview]
Message-ID: <20190708231318.1a721ce8@cakuba.netronome.com> (raw)
In-Reply-To: <156261310104.31108.4569969631798277807.stgit@ubuntu3-kvm1>
On Mon, 08 Jul 2019 19:13:29 +0000, John Fastabend wrote:
> Resolve a series of splats discovered by syzbot and an unhash
> TLS issue noted by Eric Dumazet.
>
> The main issues revolved around interaction between TLS and
> sockmap tear down. TLS and sockmap could both reset sk->prot
> ops creating a condition where a close or unhash op could be
> called forever. A rare race condition resulting from a missing
> rcu sync operation was causing a use after free. Then on the
> TLS side dropping the sock lock and re-acquiring it during the
> close op could hang. Finally, sockmap must be deployed before
> tls for current stack assumptions to be met. This is enforced
> now. A feature series can enable it.
>
> To fix this first refactor TLS code so the lock is held for the
> entire teardown operation. Then add an unhash callback to ensure
> TLS can not transition from ESTABLISHED to LISTEN state. This
> transition is a similar bug to the one found and fixed previously
> in sockmap. Then apply three fixes to sockmap to fix up races
> on tear down around map free and close. Finally, if sockmap
> is destroyed before TLS we add a new ULP op update to inform
> the TLS stack it should not call sockmap ops. This last one
> appears to be the most commonly found issue from syzbot.
Looks like strparser is not done'd for offload?
About patch 6 - I was recently wondering about the "impossible" syzbot
report where context is not freed and my conclusion was that there
can be someone sitting at lock_sock() in tcp_close() already by the
time we start installing the ULP, so TLS's close will never get called.
The entire replacing of callbacks business is really shaky :(
Perhaps I'm rumbling, I will take a close look after I get some sleep :)
next prev parent reply other threads:[~2019-07-09 6:13 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-08 19:13 [bpf PATCH v2 0/6] bpf: sockmap/tls fixes John Fastabend
2019-07-08 19:13 ` [bpf PATCH v2 1/6] tls: remove close callback sock unlock/lock and flush_sync John Fastabend
2019-07-08 19:14 ` [bpf PATCH v2 2/6] bpf: tls fix transition through disconnect with close John Fastabend
2019-07-10 2:45 ` Jakub Kicinski
2019-07-10 3:39 ` John Fastabend
2019-07-10 19:34 ` Jakub Kicinski
2019-07-10 20:04 ` Jakub Kicinski
2019-07-11 16:47 ` John Fastabend
2019-07-11 18:32 ` Jakub Kicinski
2019-07-11 21:25 ` John Fastabend
2019-07-12 3:16 ` Jakub Kicinski
2019-07-15 20:58 ` John Fastabend
2019-07-11 16:35 ` John Fastabend
2019-07-08 19:14 ` [bpf PATCH v2 3/6] bpf: sockmap, sock_map_delete needs to use xchg John Fastabend
2019-07-08 19:14 ` [bpf PATCH v2 4/6] bpf: sockmap, synchronize_rcu before free'ing map John Fastabend
2019-07-08 19:15 ` [bpf PATCH v2 5/6] bpf: sockmap, only create entry if ulp is not already enabled John Fastabend
2019-07-08 19:15 ` [bpf PATCH v2 6/6] bpf: sockmap/tls, close can race with map free John Fastabend
2019-07-10 2:36 ` Jakub Kicinski
2019-07-10 2:38 ` Jakub Kicinski
2019-07-10 3:33 ` John Fastabend
2019-07-10 19:35 ` Jakub Kicinski
2019-07-11 16:39 ` John Fastabend
2019-07-09 6:13 ` Jakub Kicinski [this message]
2019-07-09 15:40 ` [bpf PATCH v2 0/6] bpf: sockmap/tls fixes John Fastabend
2019-07-10 0:04 ` Jakub Kicinski
2019-07-10 2:21 ` Jakub Kicinski
2019-07-10 3:28 ` 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=20190708231318.1a721ce8@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=edumazet@google.com \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.org \
/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).