All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Yuran Pereira <yuran.pereira@hotmail.com>
Cc: bpf@vger.kernel.org, andrii@kernel.org,
	andrii.nakryiko@gmail.com, mykolal@fb.com, ast@kernel.org,
	martin.lau@linux.dev, song@kernel.org, john.fastabend@gmail.com,
	kpsingh@kernel.org, sdf@google.com, haoluo@google.com,
	jolsa@kernel.org, shuah@kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [PATCH bpf-next v2 1/4] selftests/bpf: Replaces the usage of CHECK calls for ASSERTs in bpf_tcp_ca
Date: Mon, 20 Nov 2023 11:00:17 -0800	[thread overview]
Message-ID: <be025c4d-4602-4b2f-963c-5ec2561cc255@linux.dev> (raw)
In-Reply-To: <GV1PR10MB6563596BC3E2B01F664010C7E8B4A@GV1PR10MB6563.EURPRD10.PROD.OUTLOOK.COM>


On 11/20/23 12:15 PM, Yuran Pereira wrote:
> Hello Yonghong,
> On Mon, Nov 20, 2023 at 07:22:59AM -0800, Yonghong Song wrote:
>>> -		if (CHECK(!err || errno != ENOENT,
>>> -			  "bpf_map_lookup_elem(sk_stg_map)",
>>> -			  "err:%d errno:%d\n", err, errno))
>>> +		if (!ASSERT_NEQ(err, 0, "bpf_map_lookup_elem(sk_stg_map)") ||
>> !ASSERT_ERR(err, "bpf_map_lookup_elem(sk_stg_map)")
>> might be simpler than !ASSERT_NEQ(..).
>>
> Sure, that makes sense. I'll change it in v3.
>>> -	pthread_join(srv_thread, &thread_ret);
>>> -	CHECK(IS_ERR(thread_ret), "pthread_join", "thread_ret:%ld",
>>> -	      PTR_ERR(thread_ret));
>>> +	err = pthread_join(srv_thread, &thread_ret);
>>> +	ASSERT_OK(err, "pthread_join");
>> The above is not equivalent to the original code.
>> The original didn't check pthread_join() return as it
>> is very very unlikely to fail. And check 'thread_ret'
>> is still needed.
>>
> Yes that is true, but the v1 [1] broke the tests because the
> ASSERT_OK_PTR(thread_ret, "pthread_join") kept failing, even
> though all the asserts within the `server()` function itself
> passed.
>
> Also, isn't asserting `thread_ret` technically checking the
> `server()` function instead of `pthread_join`? So should we
> have two asserts here? One for `server` and one for `pthread_join`
> or is it not necessary?
> i.e:
> ```
> ASSERT_OK_PTR(thread_ret, "server");
> ASSERT_OK(err, "pthread_join");
> ```

As I mentioned, checking return value of pthread_join()
is not critical as in general pthread_join() not fail.
The test is not to test pthread_join() and if pthread_join()
fails it would be an even bigger problem affecting many other
tests.

>
> Upon taking a second look, I now think that the reason why
> `ASSERT_OK_PTR(thread_ret, "pthread_join");` failed in v1 might
> have been because it calls `libbpf_get_error` which returns
> `-errno` when the pointer is `NULL`.
>
> Since `server`'s return value is not a bpf address, which
> `ASSERT_OK_PTR` expects it to be, do you that think we should
> explicitly set `errno = 0` prior to returning NULL on server?
> That way that assert would pass even when the pointer is NULL
> (which is the case when `server` returns successfuly).

Let us just do

   ASSERT_OK(IS_ERR(thread_ret), "thread_ret")


>
> [1] - https://lore.kernel.org/lkml/GV1PR10MB6563A0BE91080E6E8EC2651DE8B0A@GV1PR10MB6563.EURPRD10.PROD.OUTLOOK.COM/
>
> As always, thank you for your feedback.
>
> Yuran Pereira
>

  reply	other threads:[~2023-11-20 19:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-18 18:40 [PATCH bpf-next v2 0/4] selftests/bpf: Update multiple prog_tests to use ASSERT_ macros Yuran Pereira
2023-11-18 18:42 ` [PATCH bpf-next v2 1/4] selftests/bpf: Replaces the usage of CHECK calls for ASSERTs in bpf_tcp_ca Yuran Pereira
2023-11-20 15:22   ` Yonghong Song
2023-11-20 17:15     ` Yuran Pereira
2023-11-20 19:00       ` Yonghong Song [this message]
2023-11-18 18:44 ` [PATCH bpf-next v2 2/4] selftests/bpf: Replaces the usage of CHECK calls for ASSERTs in bind_perm Yuran Pereira
2023-11-20 15:24   ` Yonghong Song
2023-11-18 18:45 ` [PATCH bpf-next v2 3/4] selftests/bpf: Replaces the usage of CHECK calls for ASSERTs in bpf_obj_id Yuran Pereira
2023-11-20 15:41   ` Yonghong Song
2023-11-18 18:47 ` [PATCH bpf-next v2 4/4] selftests/bpf: Replaces the usage of CHECK calls for ASSERTs in vmlinux Yuran Pereira
2023-11-20 15:44   ` Yonghong Song

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=be025c4d-4602-4b2f-963c-5ec2561cc255@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=sdf@google.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=yuran.pereira@hotmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.