From patchwork Tue Sep 26 03:52:58 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 13398631 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 522B97F; Tue, 26 Sep 2023 03:53:08 +0000 (UTC) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2EC6FDF; Mon, 25 Sep 2023 20:53:06 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1c5c91bec75so54096545ad.3; Mon, 25 Sep 2023 20:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695700385; x=1696305185; 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=JczkQqyjvbmONdfSb7+32cq+PF9W34IrY/qRu2iyGPw=; b=cpreYhigLnsyABIxzWIqZndgFppxJ5zubpYiJzHBkqwyF6cuzpSnwk2lCdTZWQiun1 zIBc8wgSz9FjXsqZGr6/yJb+D10qs4JdUI3xi9WxyjmmwZCcauU8qN8UlfhvVWe0mS5H o+TQN06JTLsM4NTw4LjAydKuVx/TY+PEKo/XDzfzha2IrGNYMM0s+jc1VjX79+wakASv 2FyzqWnmDFMlHqtF+zsxbV71H3YorjnfknbIsl9nvNhoInMDUMh3Ld+wjUgoqKaXUMwp KlSjyXJvG9N3qn7HQEv6p+L8HqYgVUN5cLM45ym5vbTKff7xmm1vxHyDcuWXnrgbZx8O 8lqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695700385; x=1696305185; 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=JczkQqyjvbmONdfSb7+32cq+PF9W34IrY/qRu2iyGPw=; b=eJUufKD7otDg8DMfRM0/g6XnN3LTWdxWtUuqbvr9i4RV3iALVRfIBvbvgN8nelWL3S 2tkaL/g0I4bRufsaqNyFmKRMMZUzNYQzZKxoHlLjpj2Q7BdaIYrQT+FffvMubpHBSstB Wkk9QvmVTToRRB+wLCbXp0W5vh2w+mqoQN3AbHCkeBWeq4rV5HGL6C/JUDWmBH0Og0w3 zg4yrrMSGEBAAIDIBpj42eqeItj8zsVXvD4wrAz37QkvgCtEf2OKbwsoSm7jgXuBxqpY 2U1xwvRqcAluSzf/7dvb2Tra9wcOuxjAylCy/x9uZyPyXcSsVR2BvDf+gIy0uB96H2vR QNhg== X-Gm-Message-State: AOJu0Ywo4X1pmT4NL+f6gw8VEti4FUNyYLHMMT0ERkdsA+mJ1kYZG2FR KQ6h642wEaMsmlCdHb97JR8= X-Google-Smtp-Source: AGHT+IE8huCdkc1BY3hAVrDUH/gxQKmcK1kP6UsLX/uOMlOqEz+Y/wpKJ35spo3zhY9FlGI8Wc5pbw== X-Received: by 2002:a17:902:d503:b0:1c0:e6e1:4a11 with SMTP id b3-20020a170902d50300b001c0e6e14a11mr7457393plg.54.1695700385595; Mon, 25 Sep 2023 20:53:05 -0700 (PDT) Received: from john.lan ([2605:59c8:148:ba00:650a:2e28:f286:c10b]) by smtp.gmail.com with ESMTPSA id y15-20020a17090322cf00b001c3e732b8dbsm9755723plg.168.2023.09.25.20.53.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 20:53:05 -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 v3 1/3] bpf: tcp_read_skb needs to pop skb regardless of seq Date: Mon, 25 Sep 2023 20:52:58 -0700 Message-Id: <20230926035300.135096-2-john.fastabend@gmail.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20230926035300.135096-1-john.fastabend@gmail.com> References: <20230926035300.135096-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_BLOCKED,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 | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 0c3040a63ebd..3f66cdeef7de 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -1621,16 +1621,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 +1640,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 Tue Sep 26 03:52:59 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 13398632 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 A6E9F1871; Tue, 26 Sep 2023 03:53:08 +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 A2CF4BF; Mon, 25 Sep 2023 20:53:07 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1c5ff5f858dso28181785ad.2; Mon, 25 Sep 2023 20:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695700387; x=1696305187; 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=HtmXpIji2GdJDD3PGIdnsvoKl7h7PoK7NMP5lX5SbYc=; b=aExA4ZHUBgoluxLAmvV3nVWrOYmLclFWMkTlbWLzByFOBP1myI3HBkw17Z3LImnCd7 VZFwoPW3aw8fQs8CWxjlLeQHu/UqlXcZ0/SQiqZzX02OJTz9nONwcco8AVP9OPxyxg3z id0LeWA/1mOSI67+G7EXU7HvAN+cednXcQBih48O0Ag1JgWM4MXD20r9dacHKf8UpCZc Wl/qPeDEQCmlZv4QtIHfBcpy/rUgABVhl7/6v/zm3rAeywyHRKTP1XsfmqdrFiv5mEPZ a6gaP0SSl1UQ73nym+/KFKLPz592J3lDP4YuwR9rYBhTHCbss1m9bVLx9KkC0Jf0yu2M l3Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695700387; x=1696305187; 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=HtmXpIji2GdJDD3PGIdnsvoKl7h7PoK7NMP5lX5SbYc=; b=X8s/tNophbg/wbhlmjBZoDI5eL1UZqOimYg+igHDir4usUSHIzWDjiAhixqucMwebx CaUV+t948RipAiHER+BSxqgHrvDthnty7beq6vR/E3FGnV2ltNasL8dndLz/w8LnKgNL VfU+h/8KKl+DDk6oKGVJauVqarHFYdWX//sauAwzuDr6yhq2NFoUFwYkRay9LUGZ8itH X6nYmqiUR4gyUlCQTUFUTdKdIacRy7IkQce2wMxzrgH2CvtRn0T//kzxLmj9+Gs49/39 B8SXzmiH29TY/BJi+VHITAE8dqKc0J9iZCA/ddD5PogxL2afzdyeDLMi+Kde6R7h1C6/ vylA== X-Gm-Message-State: AOJu0YzN8CRav0g96kqVx2WpT+Sfl1k9OB6hzP3pBBMgBMYyMohtE82L s7AJStDY8ADv/sRsZzqnDgQ= X-Google-Smtp-Source: AGHT+IE9TRSHjLYIyHx0EfjiOL8BU6UNvPZPbCRHud2Hb6ZWS5iww1Fr/B+dsv/wCYO2IKUYWm3rvg== X-Received: by 2002:a17:902:be06:b0:1c1:e4f8:a5a9 with SMTP id r6-20020a170902be0600b001c1e4f8a5a9mr6188578pls.34.1695700387068; Mon, 25 Sep 2023 20:53:07 -0700 (PDT) Received: from john.lan ([2605:59c8:148:ba00:650a:2e28:f286:c10b]) by smtp.gmail.com with ESMTPSA id y15-20020a17090322cf00b001c3e732b8dbsm9755723plg.168.2023.09.25.20.53.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 20:53:06 -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 v3 2/3] bpf: sockmap, do not inc copied_seq when PEEK flag set Date: Mon, 25 Sep 2023 20:52:59 -0700 Message-Id: <20230926035300.135096-3-john.fastabend@gmail.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20230926035300.135096-1-john.fastabend@gmail.com> References: <20230926035300.135096-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_BLOCKED,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()") 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 Tue Sep 26 03:53:00 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 13398633 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 2D60A7F; Tue, 26 Sep 2023 03:53:10 +0000 (UTC) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 06CA4EC; Mon, 25 Sep 2023 20:53:09 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-68bed2c786eso6056906b3a.0; Mon, 25 Sep 2023 20:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695700388; x=1696305188; 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=yRax94hCwOhKc7hyYJNfFzu7McWGtMtmigQv48BjD80=; b=WIox8li/GrKXMDVzILOBjJ4+DjrlOccIOVDjI9bFcNZ+UQLEIAhqxqwec0Y1H/CkpM grF7SlHTLDPFQE/3YzL6FQaLunUR+lOc5tIvIwnhTLDvXAigk362IINAQl7R8DEeng8e M+KnRI72lchHu8UtSi4NRvcoBQIx8eQ53eGn7Z/Xyd9xkCT4+W+6gi8H7KIYxH6pmP5I cKZTVryjssO0yeBs85MlQnNdKU6eowbL82NvdOJrGhrqjLZXWg/cuO1cT1EysNArCID9 llqPvkQCiqauKRmx6LvNxWq9Zfwee60/6UwRiedMVpub9La2nXVEpYPxcpFTtOF+vLHw 3P9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695700388; x=1696305188; 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=yRax94hCwOhKc7hyYJNfFzu7McWGtMtmigQv48BjD80=; b=BRsZK/RkVGxpEEcAQWin6+VjDNwP8hoSOkPtWPqiVS7oNOK81n+7j1Ctat9GyoBgzh Ir2HyI9Pm37NThT5w9ACJjjnenZqYhAqSwEZKnuMeuPm4zXDuxIZogJ9nt0w/xYl9nbY ULOPwIU342x/kvj073fIT/ErnVnWnow8RPtcF4DDhxxDDSJg3KJs+gG6h1YfC2OhKo8Y 4Ecl/WpTUyZV/9vBH+sKWi8yGrec8SYOkjzsm14qnJusYYdSB/qLU/CYcg0Ui1ZwCvyi bdYj8m6Kf9kJaDkn/Vdy6vHzYl7O3CmAlKPQDkBP3Si9as/obbpcTciX2vytkY6hV4e4 /G0Q== X-Gm-Message-State: AOJu0YyfjpTfSEQfphnDA57r3lZ6HCevEd3y3UDnmW5fZKmxp+FVc08Q PT8Y/6gd/GFx+9mK4wawwXc= X-Google-Smtp-Source: AGHT+IGgYhCEEqqY0LM/oTX4SyS1xhja0vFOHCuI+yqvROcHG+LZ2nXxw+2fIWlFwHq/bosMzmKfFw== X-Received: by 2002:a05:6a20:9699:b0:147:fd40:2482 with SMTP id hp25-20020a056a20969900b00147fd402482mr6436800pzc.44.1695700388435; Mon, 25 Sep 2023 20:53:08 -0700 (PDT) Received: from john.lan ([2605:59c8:148:ba00:650a:2e28:f286:c10b]) by smtp.gmail.com with ESMTPSA id y15-20020a17090322cf00b001c3e732b8dbsm9755723plg.168.2023.09.25.20.53.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 20:53:08 -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 v3 3/3] bpf: sockmap, add tests for MSG_F_PEEK Date: Mon, 25 Sep 2023 20:53:00 -0700 Message-Id: <20230926035300.135096-4-john.fastabend@gmail.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20230926035300.135096-1-john.fastabend@gmail.com> References: <20230926035300.135096-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_BLOCKED,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. 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(); }