From: John Fastabend <john.fastabend@gmail.com>
To: Martin KaFai Lau <kafai@fb.com>
Cc: ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org
Subject: Re: [bpf PATCH 4/6] bpf: sockmap, tcp_disconnect to listen transition
Date: Wed, 13 Jun 2018 22:48:58 -0700 [thread overview]
Message-ID: <2bc8beab-4b38-851b-cefa-523c5f1a1fcf@gmail.com> (raw)
In-Reply-To: <20180614005601.bsjijlsr7smpngde@kafai-mbp>
On 06/13/2018 05:56 PM, Martin KaFai Lau wrote:
> On Wed, Jun 13, 2018 at 10:50:14AM -0700, John Fastabend wrote:
>> After adding checks to ensure TCP is in ESTABLISHED state when a
>> sock is added we need to also ensure that user does not transition
>> through tcp_disconnect() and back into ESTABLISHED state without
>> sockmap removing the sock.
>>
>> To do this add unhash hook and remove sock from map there.
> In bpf_tcp_init():
> sk->sk_prot = &tcp_bpf_proto;
>
> I may have missed a lock while reading sockmap.c.
> Is it possible that tcp_disconnect() is being called while
> the above assignment is also being done (e.g. through BPF_MAP_UPDATE_ELEM)?
> The same situation go for the ESTABLISHED check.
>
Right because ESTABLISHED is checked without any locking its
possible that the state changes during the update (from userspce
BPF_MAP_UPDATE, from sock_ops program it is locked). I have
the below patch on my tree now, I was thinking to send it as
a follow on but on second thought it likely makes more sense
as part of the patch that adds the ESTABLISHED check.
Also after the below the sk_callback lock used to protect
psock->maps is becoming increasingly pointless it allows the
delete and map free ops to be called without taking the full
sock lock. It might be time to just drop it in bpf-next and
use the sock lock in the delete cases. The more annoying part
will be the delete will have to have different userspace and
bpf program helpers so we know when we need the lock.
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -2074,17 +2074,20 @@ static int sock_map_update_elem(struct bpf_map *map,
return -EINVAL;
}
+ lock_sock(skops.sk);
/* ULPs are currently supported only for TCP sockets in ESTABLISHED
* state.
*/
if (skops.sk->sk_type != SOCK_STREAM ||
skops.sk->sk_protocol != IPPROTO_TCP ||
skops.sk->sk_state != TCP_ESTABLISHED) {
- fput(socket->file);
- return -EOPNOTSUPP;
+ err = -EOPNOTSUPP;
+ goto out;
}
err = sock_map_ctx_update_elem(&skops, map, key, flags);
+out:
+ release_sock(skops.sk);
fput(socket->file);
return err;
}
@@ -2423,17 +2426,20 @@ static int sock_hash_update_elem(struct bpf_map
*map,
return -EINVAL;
}
+ lock_sock(skops.sk);
/* ULPs are currently supported only for TCP sockets in ESTABLISHED
* state.
*/
if (skops.sk->sk_type != SOCK_STREAM ||
skops.sk->sk_protocol != IPPROTO_TCP ||
skops.sk->sk_state != TCP_ESTABLISHED) {
- fput(socket->file);
- return -EOPNOTSUPP;
+ err = -EOPNOTSUPP;
+ goto out;
}
err = sock_hash_ctx_update_elem(&skops, map, key, flags);
+out:
+ release_sock(skops.sk);
fput(socket->file);
return err;
next prev parent reply other threads:[~2018-06-14 5:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-13 17:49 [bpf PATCH 0/6] BPF fixes for sockhash John Fastabend
2018-06-13 17:49 ` [bpf PATCH 1/6] bpf: sockmap, fix crash when ipv6 sock is added John Fastabend
2018-06-13 17:50 ` [bpf PATCH 2/6] bpf: sockmap only allow ESTABLISHED sock state John Fastabend
2018-06-13 17:50 ` [bpf PATCH 3/6] bpf: sockhash fix omitted bucket lock in sock_close John Fastabend
2018-06-13 17:50 ` [bpf PATCH 4/6] bpf: sockmap, tcp_disconnect to listen transition John Fastabend
2018-06-14 0:56 ` Martin KaFai Lau
2018-06-14 5:48 ` John Fastabend [this message]
2018-06-14 16:47 ` John Fastabend
2018-06-13 17:50 ` [bpf PATCH 5/6] bpf: sockhash, add release routine John Fastabend
2018-06-13 17:50 ` [bpf PATCH 6/6] bpf: selftest remove attempts to add LISTEN sockets to sockmap 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=2bc8beab-4b38-851b-cefa-523c5f1a1fcf@gmail.com \
--to=john.fastabend@gmail.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=kafai@fb.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).