linux-kernel - Re: [PATCH bpf-next 1/5] selftests/bpf: sockmap_redir: Simplify try

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <877by663t3.fsf@cloudflare.com>
Date: Wed, 10 Sep 2025 11:43:20 +0200
From: Jakub Sitnicki <jakub@...udflare.com>
To: Michal Luczaj <mhal@...x.co>
Cc: Alexei Starovoitov <ast@...nel.org>,  Daniel Borkmann
 <daniel@...earbox.net>,  Andrii Nakryiko <andrii@...nel.org>,  Martin
 KaFai Lau <martin.lau@...ux.dev>,  Eduard Zingerman <eddyz87@...il.com>,
  Song Liu <song@...nel.org>,  Yonghong Song <yonghong.song@...ux.dev>,
  John Fastabend <john.fastabend@...il.com>,  KP Singh
 <kpsingh@...nel.org>,  Stanislav Fomichev <sdf@...ichev.me>,  Hao Luo
 <haoluo@...gle.com>,  Jiri Olsa <jolsa@...nel.org>,  Mykola Lysenko
 <mykolal@...com>,  Shuah Khan <shuah@...nel.org>,  bpf@...r.kernel.org,
  linux-kselftest@...r.kernel.org,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next 1/5] selftests/bpf: sockmap_redir: Simplify
 try_recv()

On Tue, Sep 09, 2025 at 11:25 PM +02, Michal Luczaj wrote:
> On 9/9/25 12:15, Jakub Sitnicki wrote:
>> On Tue, Sep 09, 2025 at 11:51 AM +02, Jakub Sitnicki wrote:
>>> On Fri, Sep 05, 2025 at 01:11 PM +02, Michal Luczaj wrote:
>>>> try_recv() was meant to support both @expect_success cases, but all the
>>>> callers use @expect_success=false anyway. Drop the unused logic and fold in
>>>> MSG_DONTWAIT. Adapt callers.
>>>>
>>>> Subtle change here: recv() return value of 0 will also be considered (an
>>>> unexpected) success.
>>>>
>>>> Signed-off-by: Michal Luczaj <mhal@...x.co>
>>>> ---
>>>>  .../selftests/bpf/prog_tests/sockmap_redir.c       | 25 +++++++++-------------
>>>>  1 file changed, 10 insertions(+), 15 deletions(-)
>>>>
>>>> diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_redir.c b/tools/testing/selftests/bpf/prog_tests/sockmap_redir.c
>>>> index 9c461d93113db20de65ac353f92dfdbe32ffbd3b..c1bf1076e8152b7d83c3e07e2dce746b5a39cf7e 100644
>>>> --- a/tools/testing/selftests/bpf/prog_tests/sockmap_redir.c
>>>> +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_redir.c
>>>> @@ -144,17 +144,14 @@ static void get_redir_params(struct redir_spec *redir,
>>>>  		*redirect_flags = 0;
>>>>  }
>>>>  
>>>> -static void try_recv(const char *prefix, int fd, int flags, bool expect_success)
>>>> +static void fail_recv(const char *prefix, int fd, int more_flags)
>>>>  {
>>>>  	ssize_t n;
>>>>  	char buf;
>>>>  
>>>> -	errno = 0;
>>>> -	n = recv(fd, &buf, 1, flags);
>>>> -	if (n < 0 && expect_success)
>>>> -		FAIL_ERRNO("%s: unexpected failure: retval=%zd", prefix, n);
>>>> -	if (!n && !expect_success)
>>>> -		FAIL("%s: expected failure: retval=%zd", prefix, n);
>>>> +	n = recv(fd, &buf, 1, MSG_DONTWAIT | more_flags);
>>>> +	if (n >= 0)
>>>> +		FAIL("%s: unexpected success: retval=%zd", prefix, n);
>>>>  }
>>>
>>> This bit, which you highlighted in the description, I don't get.
>>>
>>> If we're expecting to receive exactly one byte, why treat a short read
>>> as a succcess? Why not make it a strict "n != 1" check?
>>>
>>> [...]
>> 
>> Nevermind. It makes sense now. We do want to report a failure for 0-len
>> msg recv as well. You're effectively checking if the rcv queue is empty.
>> 
>> I'd add MSG_PEEK, to signal that we're _just checking_ if the socket is
>> readable, and turn the check into the below to succeed only when
>> queue is empty:
>> 
>>         (n != -1 || (errno != EAGAIN && errno != EWOULDBLOCK))
>
> Well, looks like adding MSG_PEEK exposed a bug in the test. I'll fix that.

The gift that keeps on giving xD

Other alternatives that should also work, but who knows:

- select/poll/epoll readability check
- ioctl(SIOCINQ) but no way to tell if 0-len msg is pending