Re: [PATCH v2 3/3] selftests/hid: prepare test_rdesc_fixup_get_data_overflow for the new verifier

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Medium] The test silently passes on any program load failure, masking unrelated infrastructure issues.

Pre-existing issues:
- [High] Using TEARDOWN_LOG with ASSERT_OK_PTR causes FIXTURE_TEARDOWN to execute twice, leading to undefined behavior (double pthread_join).
- [High] Teardown deadlock with uhid background thread on assertion failure.
--

--- Patch [3]: [PATCH v2 3/3] selftests/hid: prepare test_rdesc_fixup_get_data_overflow for the new verifier ---
commit 2045d9e4296113259f889a7b753ecfe091d15ecf
Author: Benjamin Tissoires <bentiss@kernel.org>

selftests/hid: prepare test_rdesc_fixup_get_data_overflow for the new verifier

The new verifier in the bpf-next branch is now capable of detecting the
overflow that was triggered by test_rdesc_fixup_get_data_overflow.
This is better in terms of UI, but now the test is failing and should be
marked as expected to fail.

Add a new parameter to load_programs() when we expect the test to fail,
and dynamically validate the test by checkcing if it loads (it should
fail to load with new verifier), but if it still loads, HID-BPF should
detect the overflow itself and return an error in hid_bpf_get_data().

> diff --git a/tools/testing/selftests/hid/hid_bpf.c b/tools/testing/selftests/hid/hid_bpf.c
> index 069ebdbb4d1c4..7ab86296ff236 100644
> --- a/tools/testing/selftests/hid/hid_bpf.c
> +++ b/tools/testing/selftests/hid/hid_bpf.c
> @@ -67,14 +67,17 @@ struct test_program {
>  	int insert_head;
>  };
>  #define LOAD_PROGRAMS(progs) \
> -	load_programs(progs, ARRAY_SIZE(progs), _metadata, self, variant)
> +	load_programs(progs, ARRAY_SIZE(progs), false, _metadata, self, variant)
> +#define LOAD_PROGRAMS_MAY_FAIL(progs) \
> +	load_programs(progs, ARRAY_SIZE(progs), true, _metadata, self, variant)
>  #define LOAD_BPF \
> -	load_programs(NULL, 0, _metadata, self, variant)
> -static void load_programs(const struct test_program programs[],
> -			  const size_t progs_count,
> -			  struct __test_metadata *_metadata,
> -			  FIXTURE_DATA(hid_bpf) * self,
> -			  const FIXTURE_VARIANT(hid_bpf) * variant)
> +	load_programs(NULL, 0, false, _metadata, self, variant)
> +static int load_programs(const struct test_program programs[],
> +			 const size_t progs_count,
> +			 bool load_may_fail,
> +			 struct __test_metadata *_metadata,
> +			 FIXTURE_DATA(hid_bpf) * self,
> +			 const FIXTURE_VARIANT(hid_bpf) * variant)
>  {
>  	struct bpf_map *iter_map;
>  	int err = -EINVAL;

[Severity: High]
This is a pre-existing issue, but does using TEARDOWN_LOG with ASSERT_OK_PTR
inside load_programs() cause FIXTURE_TEARDOWN to execute twice?

If hid__open() fails in this function and returns NULL:

tools/testing/selftests/hid/hid_bpf.c:load_programs() {
    self->skel = hid__open();
    ASSERT_OK_PTR(self->skel) TEARDOWN_LOG("Error while calling hid__open");

ASSERT_OK_PTR() evaluates as false and executes its optional handler
TEARDOWN_LOG(), which directly calls hid_bpf_teardown() and pthread_join().

Afterward, the kselftest_harness __bail() mechanism triggers the test
framework's wrapper teardown:

tools/testing/selftests/kselftest_harness.h:wrapper_##fixture_name##_##test_name##_teardown() {
    if (fixture_name##_teardown_parent == in_parent && \
        !__atomic_test_and_set(_metadata->no_teardown, __ATOMIC_RELAXED)) \
        fixture_name##_teardown(_metadata, self, variant); \
}

Since _metadata->no_teardown wasn't updated by TEARDOWN_LOG, this calls
hid_bpf_teardown() a second time. Can this result in undefined behavior
crashing the test runner child process via a segfault?

[ ... ]

> @@ -904,7 +911,9 @@ TEST_F(hid_bpf, test_rdesc_fixup_get_data_overflow)
>  		{ .name = "hid_rdesc_fixup_get_data_overflow" },
>  	};
>  
> -	LOAD_PROGRAMS(progs);
> +	/* newer verifier can detect the overflow at load time */
> +	if (LOAD_PROGRAMS_MAY_FAIL(progs))
> +		return;
>  
>  	ASSERT_EQ(self->skel->bss->get_data_overflow_check, 1);
>  }

[Severity: Medium]
Does returning on any load failure silently mark the test as PASSED?

If hid__load(self->skel) fails for an unrelated infrastructure reason
(e.g., -ENOMEM), load_programs() will return that error code and make
LOAD_PROGRAMS_MAY_FAIL(progs) truthy. The test then executes a normal
return, exiting with a 0 status.

Should the test instead verify that the program was specifically rejected
by the verifier with the expected error code?

[Severity: High]
This is a pre-existing issue, but is there a potential teardown deadlock in
test_hid_user_output_report_call() on assertion failure?

If an assertion fails while the main thread holds uhid_output_mtx:

tools/testing/selftests/hid/hid_bpf.c:test_hid_user_output_report_call() {
    pthread_mutex_lock(&uhid_output_mtx);
    ...
    ASSERT_EQ(args.retval, 3);
    ...
    pthread_mutex_unlock(&uhid_output_mtx);
}

The test executes __bail() and initiates teardown without releasing the mutex.
Teardown sends a UHID_DESTROY event and blocks on pthread_join(self->hid.tid).

Concurrently, the listener thread might process a UHID_OUTPUT event:

tools/testing/selftests/hid/hid_common.h:uhid_event() {
    case UHID_OUTPUT:
        ...
        pthread_mutex_lock(&uhid_output_mtx);
        ...
        pthread_mutex_unlock(&uhid_output_mtx);
        break;
}

Does this cause the listener thread to block indefinitely attempting to
acquire uhid_output_mtx, which in turn causes pthread_join to hang in the
main thread?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260825-wip-bpf-safe-v2-0-d044355c09d8@kernel.org?part=3