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 <m...@rbox.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.

Thanks,
Michal


Reply via email to