bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: alexei.starovoitov@gmail.com, daniel@iogearbox.net, andrii@kernel.org
Cc: john.fastabend@gmail.com, bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: [PATCH bpf 2/2] bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap
Date: Fri, 19 Nov 2021 10:14:18 -0800	[thread overview]
Message-ID: <20211119181418.353932-3-john.fastabend@gmail.com> (raw)
In-Reply-To: <20211119181418.353932-1-john.fastabend@gmail.com>

When a sock is added to a sock map we evaluate what proto op hooks need
to be used. However, when the program is removed from the sock map
we have not been evaluating if that changes the required program layout.

Before the patch listed in the 'fixes' tag this was not causing failures
because the base program set handles all cases. Specifically, the case
with a stream parser and the case with out a stream parser are both
handled. With the fix below we identified a race when running with a
proto op that attempts to read skbs off both the stream parser and the
skb->receive_queue. Namely, that a race existed where when the stream
parser is empty checking the skb->reqceive_queue from recvmsg at the
precies moment when the parser is paused and the receive_queue is not
empty could result in skipping the stream parser. This may break a
RX policy depending on the parser to run.

The fix tag then loads a specific proto ops that resolved this race.
But, we missed removing that proto ops recv hook when the sock is
removed from the sockmap. The result is the stream parser is stopped
so no more skbs will be aggregated there, but the hook and BPF program
continues to be attached on the psock. User space will then get an
EBUSY when trying to read the socket because the recvmsg() handler
is now waiting on a stopped stream parser.

To fix we rerun the proto ops init() function which will look at the
new set of progs attached to the psock and rest the proto ops hook
to the correct handlers. And in the above case where we remove the
sock from the sock map the RX prog will no longer be listed so the
proto ops is removed.

Fixes: c5d2177a72a16 ("bpf, sockmap: Fix race in ingress receive verdict with redirect to self")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
 net/core/skmsg.c    | 5 +++++
 net/core/sock_map.c | 5 ++++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/net/core/skmsg.c b/net/core/skmsg.c
index 1ae52ac943f6..8eb671c827f9 100644
--- a/net/core/skmsg.c
+++ b/net/core/skmsg.c
@@ -1124,6 +1124,8 @@ void sk_psock_start_strp(struct sock *sk, struct sk_psock *psock)
 
 void sk_psock_stop_strp(struct sock *sk, struct sk_psock *psock)
 {
+	psock_set_prog(&psock->progs.stream_parser, NULL);
+
 	if (!psock->saved_data_ready)
 		return;
 
@@ -1212,6 +1214,9 @@ void sk_psock_start_verdict(struct sock *sk, struct sk_psock *psock)
 
 void sk_psock_stop_verdict(struct sock *sk, struct sk_psock *psock)
 {
+	psock_set_prog(&psock->progs.stream_verdict, NULL);
+	psock_set_prog(&psock->progs.skb_verdict, NULL);
+
 	if (!psock->saved_data_ready)
 		return;
 
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 9b528c644fb7..4ca4b11f4e5f 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -167,8 +167,11 @@ static void sock_map_del_link(struct sock *sk,
 		write_lock_bh(&sk->sk_callback_lock);
 		if (strp_stop)
 			sk_psock_stop_strp(sk, psock);
-		else
+		if (verdict_stop)
 			sk_psock_stop_verdict(sk, psock);
+
+		if (psock->psock_update_sk_prot)
+			psock->psock_update_sk_prot(sk, psock, false);
 		write_unlock_bh(&sk->sk_callback_lock);
 	}
 }
-- 
2.33.0


  parent reply	other threads:[~2021-11-19 18:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19 18:14 [PATCH bpf 0/2] sockmap fix for test_map failure John Fastabend
2021-11-19 18:14 ` [PATCH bpf 1/2] bpf, sockmap: Attach map progs to psock early for feature probes John Fastabend
2021-11-19 18:14 ` John Fastabend [this message]
2021-11-20  0:00 ` [PATCH bpf 0/2] sockmap fix for test_map failure patchwork-bot+netdevbpf

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=20211119181418.353932-3-john.fastabend@gmail.com \
    --to=john.fastabend@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --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).