Re: [PATCH bpf v2 14/15] selftests/bpf: Check BPFTOOL env var in detect_bpftool_path()

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 2/18/26 9:38 AM, Alexei Starovoitov wrote:
> On Tue, Feb 17, 2026 at 4:31 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> The bpftool_maps_access and bpftool_metadata tests may fail on BPF CI
>> with "command not found", depending on a workflow.
>> This happens because detect_bpftool_path() only checks two hardcoded
>> relative paths:
>>   - ./tools/sbin/bpftool
>>   - ../tools/sbin/bpftool
>>
>> Add support for a BPFTOOL environment variable that allows specifying
>> the exact path to the bpftool binary.
>>
>> Also replace strncpy() with snprintf() for proper null-termination.
>>
>> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
>> ---
>>  tools/testing/selftests/bpf/bpftool_helpers.c | 19 +++++++++++++++----
>>  1 file changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/testing/selftests/bpf/bpftool_helpers.c b/tools/testing/selftests/bpf/bpftool_helpers.c
>> index a5824945a4a5..d810e73da6c8 100644
>> --- a/tools/testing/selftests/bpf/bpftool_helpers.c
>> +++ b/tools/testing/selftests/bpf/bpftool_helpers.c
>> @@ -1,5 +1,6 @@
>>  // SPDX-License-Identifier: GPL-2.0-only
>>  #include "bpftool_helpers.h"
>> +#include <stdio.h>
>>  #include <unistd.h>
>>  #include <string.h>
>>  #include <stdbool.h>
>> @@ -12,13 +13,24 @@
>>  static int detect_bpftool_path(char *buffer)
>>  {
>>         char tmp[BPFTOOL_PATH_MAX_LEN];
>> +       const char *env_path;
>> +
>> +       /* First, check if BPFTOOL environment variable is set */
>> +       env_path = getenv("BPFTOOL");
>> +       if (env_path && access(env_path, X_OK) == 0) {
>> +               snprintf(buffer, BPFTOOL_PATH_MAX_LEN, "%s", env_path);
>> +               return 0;
>> +       } else if (env_path) {
>> +               fprintf(stderr, "bpftool '%s' doesn't exist or is not executable\n", env_path);
>> +               return 1;
>> +       }
>>
>>         /* Check default bpftool location (will work if we are running the
>>          * default flavor of test_progs)
>>          */
>>         snprintf(tmp, BPFTOOL_PATH_MAX_LEN, "./%s", BPFTOOL_DEFAULT_PATH);
>>         if (access(tmp, X_OK) == 0) {
>> -               strncpy(buffer, tmp, BPFTOOL_PATH_MAX_LEN);
>> +               snprintf(buffer, BPFTOOL_PATH_MAX_LEN, "%s", tmp);
> 
> I guess it's ok for user space, but
> 
> git log --oneline|grep "snprintf with strscpy"
> ad789a85b163 mm/cma: replace snprintf with strscpy in cma_new_area
> 674fb053e95d sparc: vio: Replace snprintf with strscpy in vio_create_one
> 2dfc417414c6 genirq/proc: Replace snprintf with strscpy in register_handler_proc
> f46ebb910989 block: Replace snprintf with strscpy in check_partition
> b66215e7b780 media: verisilicon: replace snprintf with strscpy+strlcat
> a86028f8e3ee staging: most: sound: replace snprintf with strscpy
> 
> and many others...
> So.. should we introduce strscpy() in selftests/bpf ?

I guess we can, but:

$ grep -r 'snprintf(' --include="*.[ch]" tools/testing/selftests/bpf/ | wc -l
238

The reason to prefer strscpy() is speed, right?
Can we use kernel implementation in userspace directly?

In tools/include I only see this:

	#define strscpy strcpy