From patchwork Mon Sep 25 20:24:46 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 13398395 X-Patchwork-Delegate: bpf@iogearbox.net Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F0BB623745; Mon, 25 Sep 2023 20:24:53 +0000 (UTC) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4B2110F; Mon, 25 Sep 2023 13:24:52 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1bdf4752c3cso49712685ad.2; Mon, 25 Sep 2023 13:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695673492; x=1696278292; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=JdpSeygtOSjj+3E6PMEZpW/nfaq9Hsth846hxO+B4ZE=; b=EoxCc4JLXW7otauAzhE31Smf5nWAHUqKX1oI+grVYWcl+Ce+5PCJ0zgaL+rLBzXLfT 0/I0srH+vpVjV4uxpM5q0UPkE18GivPvKxGbnGprxR9P1mqNWHq5NNfGbkO6VYEmNTQ/ Y2hTJ7VhAcETArOwL84R24zTiTEek4BrEKin2i5cShVHknuRsHxeftSVJbR76/Ho/+um fwxNV8daWaXZ7n0pV1Zo5b6U+CQ8pMzyvnsGG2sP5Ny+C4Q02BInP5sMuNGHej4Gl4oU 9FV+u/bUWxwv4ajXJYHmmn/1/ulcv2XiCE799yocprNecMRzYyVJELw6ZI+NiQXOQD/k /k5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695673492; x=1696278292; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JdpSeygtOSjj+3E6PMEZpW/nfaq9Hsth846hxO+B4ZE=; b=kNEM7CS/nmzQRCxeVj6zvznpnKTWqyjNbbwilRuZhmnEtxtAwPBweT6Yfd/kpgSz7+ Lyd3nJmwAOWJeHQrKSWVzqA7JAulPh7wrhIx70J1GTnaIicBQNJPhUcofCgXPtsglPAH 5mkYFLlbI+93hTfoc/2TmIZXbrra3YsTaeGqRTScLjLCKwUQt0/g6cIje9J1TDLmWwCN zSRqsf1iZ4hZCWDQ0n4J30s2wckxebOPj5qqk7DZ1sDQBM+bla1uzK4VeJNyEx5KC+Gx 4ga3gjC4Njhrpk4cTa4XkMnVceceZSYMmtrW/WgPfpgRSTNknS0/qesoYrwJxmricNmh B97g== X-Gm-Message-State: AOJu0Yzh8k/i2GDkHHJFrK2LkmfpVwTyDxagtv26Q4jaaUf20E2US3Pq 5pVXcB1VtBYFizpesWhpG1o= X-Google-Smtp-Source: AGHT+IEIY/jhdhIwh69/vZrZC11CfTREgOTtxWJi4zJ4oUq88N8Eey6SHrjbt6r/hewTBfZ6ADqOQg== X-Received: by 2002:a17:902:6bc3:b0:1c3:6724:db6f with SMTP id m3-20020a1709026bc300b001c36724db6fmr4706446plt.29.1695673492142; Mon, 25 Sep 2023 13:24:52 -0700 (PDT) Received: from john.lan ([2605:59c8:148:ba00:51e:699c:e63:c15a]) by smtp.gmail.com with ESMTPSA id jg6-20020a17090326c600b001c61df93afdsm2254040plb.59.2023.09.25.13.24.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 13:24:51 -0700 (PDT) From: John Fastabend To: daniel@iogearbox.net, ast@kernel.org, andrii@kernel.org, jakub@cloudflare.com Cc: john.fastabend@gmail.com, bpf@vger.kernel.org, netdev@vger.kernel.org, edumazet@google.com Subject: [PATCH bpf v2 1/3] bpf: tcp_read_skb needs to pop skb regardless of seq Date: Mon, 25 Sep 2023 13:24:46 -0700 Message-Id: <20230925202448.100920-2-john.fastabend@gmail.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20230925202448.100920-1-john.fastabend@gmail.com> References: <20230925202448.100920-1-john.fastabend@gmail.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Patchwork-Delegate: bpf@iogearbox.net Before fix e5c6de5fa0258 tcp_read_skb() would increment the tp->copied-seq value. This (as described in the commit) would cause an error for apps because once that is incremented the application might believe there is no data to be read. Then some apps would stall or abort believing no data is available. However, the fix is incomplete because it introduces another issue in the skb dequeue. The loop does tcp_recv_skb() in a while loop to consume as many skbs as possible. The problem is the call is, tcp_recv_skb(sk, seq, &offset) Where 'seq' is u32 seq = tp->copied_seq; Now we can hit a case where we've yet incremented copied_seq from BPF side, but then tcp_recv_skb() fails this test, if (offset < skb->len || (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)) so that instead of returning the skb we call tcp_eat_recv_skb() which frees the skb. This is because the routine believes the SKB has been collapsed per comment, /* This looks weird, but this can happen if TCP collapsing * splitted a fat GRO packet, while we released socket lock * in skb_splice_bits() */ This can't happen here we've unlinked the full SKB and orphaned it. Anyways it would confuse any BPF programs if the data were suddenly moved underneath it. To fix this situation do simpler operation and just skb_peek() the data of the queue followed by the unlink. It shouldn't need to check this condition and tcp_read_skb() reads entire skbs so there is no need to handle the 'offset!=0' case as we would see in tcp_read_sock(). Fixes: e5c6de5fa0258 ("bpf, sockmap: Incorrectly handling copied_seq") Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()") Signed-off-by: John Fastabend --- net/ipv4/tcp.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 0c3040a63ebd..235d77af3177 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -1622,15 +1622,13 @@ EXPORT_SYMBOL(tcp_read_sock); int tcp_read_skb(struct sock *sk, skb_read_actor_t recv_actor) { struct tcp_sock *tp = tcp_sk(sk); - u32 seq = tp->copied_seq; struct sk_buff *skb; int copied = 0; - u32 offset; if (sk->sk_state == TCP_LISTEN) return -ENOTCONN; - while ((skb = tcp_recv_skb(sk, seq, &offset)) != NULL) { + while ((skb = skb_peek(&sk->sk_receive_queue)) != NULL) { u8 tcp_flags; int used; @@ -1643,13 +1641,10 @@ int tcp_read_skb(struct sock *sk, skb_read_actor_t recv_actor) copied = used; break; } - seq += used; copied += used; - if (tcp_flags & TCPHDR_FIN) { - ++seq; + if (tcp_flags & TCPHDR_FIN) break; - } } return copied; } From patchwork Mon Sep 25 20:24:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 13398396 X-Patchwork-Delegate: bpf@iogearbox.net Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CDFA9241E5; Mon, 25 Sep 2023 20:24:55 +0000 (UTC) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4477F111; Mon, 25 Sep 2023 13:24:54 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1c465d59719so49587475ad.1; Mon, 25 Sep 2023 13:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695673494; x=1696278294; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=eGlO7iXA08+oNOe13C8SGeJOdlscizAQcKnMOa1d/SM=; b=C+xaOiZlttCEA8jpW4QQUeoteVurHWgSyMPoZoTNnuRSVYQ8VdZnzEf+cO1UdNzAHD lmJ8fdmgK53yjzwohGB+LPLQoV6rC9I58uHVNwuB5L/sigSgi+/YWiMwDbbsAMHS+oc5 sgxR4q/1ehAlHUzqHaVd8JQeeCTh9TFjt0Jrh7hfVGHgbdT612dV/t+FX7NeSKjtY9mz rOvxyHB793peOQ2hjAccdmtXSqp8nPt/IyP3K3Gebi67ED/A3FC8vMjyBg4RBBMS0dTq vmQHPmBDcq7wfkwzTCIYlAVKwYQSBRQIC8FRS9dir+N2Hz+0Qx8HXjO9HPi9n79SxVj+ Sv2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695673494; x=1696278294; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eGlO7iXA08+oNOe13C8SGeJOdlscizAQcKnMOa1d/SM=; b=bcm6smisATvdg86E9bThM3k079q9GAGW4FM16oFNf2EwBLY3lXcUnnz/3igxi0HPzr 0V2vHwbxJiBw6g55EA/VGxTWNKyF1INkOtOlxbmBb5C35M587X4Q4PM+HvtKOig/9BW9 swQjLHEUeQEnbUejQhX9/WrhH/b4FEu+Qmwp5zxcDBDxnEpT7erwYsb5Da8jciz8QzqN bpqdudS2lTqBrxfHH64Zw4IEgEjqX1Q6x+ypQByE8eGil46YE3dt6IxE+BVRApVswFUy 85mVdZn5QFsPYwidcQFLRG9pCjorqP1NrjiD8WNrUnvQfsFGjoXZ1uG3qqOpqEYny9x8 pD1w== X-Gm-Message-State: AOJu0YyQkDdE3HcNN1dScLNe65ayQ+VBjeNG5PQeOen78BAhHgD2DVJn yEdU0OVAffAmBoaxxQ8JQ2Y= X-Google-Smtp-Source: AGHT+IEf8lUeCHRUj3sx1mFKrcBRGaHkQxxAL6kyzNzA+uNr6o+AMaKp5hl1SYpXOe4iSlYOPxENDQ== X-Received: by 2002:a17:902:a714:b0:1c0:d5c6:748f with SMTP id w20-20020a170902a71400b001c0d5c6748fmr4896290plq.67.1695673493707; Mon, 25 Sep 2023 13:24:53 -0700 (PDT) Received: from john.lan ([2605:59c8:148:ba00:51e:699c:e63:c15a]) by smtp.gmail.com with ESMTPSA id jg6-20020a17090326c600b001c61df93afdsm2254040plb.59.2023.09.25.13.24.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 13:24:53 -0700 (PDT) From: John Fastabend To: daniel@iogearbox.net, ast@kernel.org, andrii@kernel.org, jakub@cloudflare.com Cc: john.fastabend@gmail.com, bpf@vger.kernel.org, netdev@vger.kernel.org, edumazet@google.com Subject: [PATCH bpf v2 2/3] bpf: sockmap, do not inc copied_seq when PEEK flag set Date: Mon, 25 Sep 2023 13:24:47 -0700 Message-Id: <20230925202448.100920-3-john.fastabend@gmail.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20230925202448.100920-1-john.fastabend@gmail.com> References: <20230925202448.100920-1-john.fastabend@gmail.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Patchwork-Delegate: bpf@iogearbox.net When data is peek'd off the receive queue we shouldn't considered it copied from tcp_sock side. When we increment copied_seq this will confuse tcp_data_ready() because copied_seq can be arbitrarily increased. From] application side it results in poll() operations not waking up when expected. Notice tcp stack without BPF recvmsg programs also does not increment copied_seq. We broke this when we moved copied_seq into recvmsg to only update when actual copy was happening. But, it wasn't working correctly either before because the tcp_data_ready() tried to use the copied_seq value to see if data was read by user yet. See fixes tags. Fixes: e5c6de5fa0258 ("bpf, sockmap: Incorrectly handling copied_seq") Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()") Reviewed-by: Jakub Sitnicki Signed-off-by: John Fastabend --- net/ipv4/tcp_bpf.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c index 81f0dff69e0b..327268203001 100644 --- a/net/ipv4/tcp_bpf.c +++ b/net/ipv4/tcp_bpf.c @@ -222,6 +222,7 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk, int *addr_len) { struct tcp_sock *tcp = tcp_sk(sk); + int peek = flags & MSG_PEEK; u32 seq = tcp->copied_seq; struct sk_psock *psock; int copied = 0; @@ -311,7 +312,8 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk, copied = -EAGAIN; } out: - WRITE_ONCE(tcp->copied_seq, seq); + if (!peek) + WRITE_ONCE(tcp->copied_seq, seq); tcp_rcv_space_adjust(sk); if (copied > 0) __tcp_cleanup_rbuf(sk, copied); From patchwork Mon Sep 25 20:24:48 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 13398397 X-Patchwork-Delegate: bpf@iogearbox.net Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 09A15241FE; Mon, 25 Sep 2023 20:24:58 +0000 (UTC) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD990112; Mon, 25 Sep 2023 13:24:55 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1c5bbb205e3so66052225ad.0; Mon, 25 Sep 2023 13:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695673495; x=1696278295; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=26fi+axt3x0k9FrIsRxv3t9BAfLZcnBuCf6adchVtJk=; b=gQk9GBuCARGuI1luKhxqBRck3PrreBKTveMDcYpEvy+uD0OLWKrTmlZoI2uceKHuK3 MVtu3UYcLvuc6M61qow+TN6IB3kGgqHuF+pogzBkhm1ng4HGclimfeu2fduKDVSut/7F gzEeaREJj3/czZgApnqb2l+80NkjRz0GLUja21wD3LWrhgh3PZXU3Hu0Me/i9jje5qU5 izrDouXC+LXRQfZlxkLm5lHMHiBWM0cYbBV6HkQLqeXoOjzcY+QJketiZlT4h71eJfPe ZS6qdTKJrDo7HQfMevIgqKdqwpE+zn0r5mPlhqqILLQqadOuEGESPUzlSAzlpFYRSjIH PfMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695673495; x=1696278295; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=26fi+axt3x0k9FrIsRxv3t9BAfLZcnBuCf6adchVtJk=; b=vH9BYDcPVrA1zWGSbqciy2TCOROdQp5yB1A7TlpWaDwqhpH05Un5yyKo1FLYZYR7Hm cO4NjFtsGxIrNq0EhxepR9lgmKrBjv2aLuSU6TSUkIjzAZXSV55Rcken1X0lwSXPoq7o 4/Vu3gdV47T/XT3vDuTTLkmGL28nPjYTQLdcHbG/uRc6X4kzJe6xzbROoKFaBDMIwcqg k58Pxz5pukKj28CCAwRPD7HgzgxauWwoMSjQeKWIX6Kz8xy0/1Mbi0wBb1MnGrPYZXIX odKaTK+RXqK7svi/GRMNKXyATFwXDwZmYwsTJlkF+LANxQwSwwDynptfRVNH5G5oYaJQ LN+w== X-Gm-Message-State: AOJu0Yw0o7xsfhQ1vDwMvSO0rJENjYksuL25dTJIdAgUGpya+j7XPAVQ iSWF5B6Pa/NkqaIb366unms= X-Google-Smtp-Source: AGHT+IFBdeW/jjK+MhzVVLeKAQD8V0G7aMTmpM5YbPbumcBI4oViM6X+VF/zcA/NkYR+ICd80UY5wg== X-Received: by 2002:a17:902:ecc6:b0:1b8:b285:ec96 with SMTP id a6-20020a170902ecc600b001b8b285ec96mr10590028plh.23.1695673495348; Mon, 25 Sep 2023 13:24:55 -0700 (PDT) Received: from john.lan ([2605:59c8:148:ba00:51e:699c:e63:c15a]) by smtp.gmail.com with ESMTPSA id jg6-20020a17090326c600b001c61df93afdsm2254040plb.59.2023.09.25.13.24.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 13:24:54 -0700 (PDT) From: John Fastabend To: daniel@iogearbox.net, ast@kernel.org, andrii@kernel.org, jakub@cloudflare.com Cc: john.fastabend@gmail.com, bpf@vger.kernel.org, netdev@vger.kernel.org, edumazet@google.com Subject: [PATCH bpf v2 3/3] bpf: sockmap, add tests for MSG_F_PEEK Date: Mon, 25 Sep 2023 13:24:48 -0700 Message-Id: <20230925202448.100920-4-john.fastabend@gmail.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20230925202448.100920-1-john.fastabend@gmail.com> References: <20230925202448.100920-1-john.fastabend@gmail.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Patchwork-Delegate: bpf@iogearbox.net Test that we can read with MSG_F_PEEK and then still get correct number of available bytes through FIONREAD. The recv() (without PEEK) then returns the bytes as expected. The recv() always worked though because it was just the available byte reporting that was broke before latest fixes. Reviewed-by: Jakub Sitnicki Signed-off-by: John Fastabend --- .../selftests/bpf/prog_tests/sockmap_basic.c | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c index 064cc5e8d9ad..e8eee2b8901e 100644 --- a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c @@ -475,6 +475,56 @@ static void test_sockmap_skb_verdict_fionread(bool pass_prog) test_sockmap_drop_prog__destroy(drop); } + +static void test_sockmap_skb_verdict_peek(void) +{ + int err, map, verdict, s, c1, p1, zero = 0, sent, recvd, avail; + struct test_sockmap_pass_prog *pass; + char snd[256] = "0123456789"; + char rcv[256] = "0"; + + pass = test_sockmap_pass_prog__open_and_load(); + if (!ASSERT_OK_PTR(pass, "open_and_load")) + return; + verdict = bpf_program__fd(pass->progs.prog_skb_verdict); + map = bpf_map__fd(pass->maps.sock_map_rx); + + err = bpf_prog_attach(verdict, map, BPF_SK_SKB_STREAM_VERDICT, 0); + if (!ASSERT_OK(err, "bpf_prog_attach")) + goto out; + + s = socket_loopback(AF_INET, SOCK_STREAM); + if (!ASSERT_GT(s, -1, "socket_loopback(s)")) + goto out; + + err = create_pair(s, AF_INET, SOCK_STREAM, &c1, &p1); + if (!ASSERT_OK(err, "create_pairs(s)")) + goto out; + + err = bpf_map_update_elem(map, &zero, &c1, BPF_NOEXIST); + if (!ASSERT_OK(err, "bpf_map_update_elem(c1)")) + goto out_close; + + sent = xsend(p1, snd, sizeof(snd), 0); + ASSERT_EQ(sent, sizeof(snd), "xsend(p1)"); + recvd = recv(c1, rcv, sizeof(rcv), MSG_PEEK); + ASSERT_EQ(recvd, sizeof(rcv), "recv(c1)"); + err = ioctl(c1, FIONREAD, &avail); + ASSERT_OK(err, "ioctl(FIONREAD) error"); + ASSERT_EQ(avail, sizeof(snd), "after peek ioctl(FIONREAD)"); + recvd = recv(c1, rcv, sizeof(rcv), 0); + ASSERT_EQ(recvd, sizeof(rcv), "recv(p0)"); + err = ioctl(c1, FIONREAD, &avail); + ASSERT_OK(err, "ioctl(FIONREAD) error"); + ASSERT_EQ(avail, 0, "after read ioctl(FIONREAD)"); + +out_close: + close(c1); + close(p1); +out: + test_sockmap_pass_prog__destroy(pass); +} + void test_sockmap_basic(void) { if (test__start_subtest("sockmap create_update_free")) @@ -515,4 +565,6 @@ void test_sockmap_basic(void) test_sockmap_skb_verdict_fionread(true); if (test__start_subtest("sockmap skb_verdict fionread on drop")) test_sockmap_skb_verdict_fionread(false); + if (test__start_subtest("sockmap skb_verdict msg_f_peek")) + test_sockmap_skb_verdict_peek(); }