From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Jiri Olsa" <olsajiri@gmail.com>,
"Mykyta Yatsenko" <yatsenko@meta.com>,
"Alexis Lothoré" <alexis.lothore@bootlin.com>,
"Amery Hung" <ameryhung@gmail.com>, bpf <bpf@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Kernel Team" <kernel-team@meta.com>
Subject: Re: [PATCH bpf v2 14/15] selftests/bpf: Check BPFTOOL env var in detect_bpftool_path()
Date: Wed, 18 Feb 2026 17:12:52 -0800 [thread overview]
Message-ID: <54cffd1f-df2f-4a01-a07d-0509425558d9@linux.dev> (raw)
In-Reply-To: <84ba9764-5ba2-4e9b-af81-3fea2682d161@linux.dev>
On 2/18/26 10:17 AM, Ihor Solodrai wrote:
> 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:
>>>
>>> [...]
>>>
>>> /* 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
>
I think we can add a simple implementation to tools/lib/string.c
See a diff below: essentially a copy from arch/s390/boot/string.c [1]
I suppose it's faster than snprintf(). However I am not sure about
going through all 238 usages, as that would touch many files. But at
least we can make actual strscpy available in selftests.
I can add this in v3. Alexei, wdyt?
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/boot/string.c?h=v6.19#n32
diff --git a/tools/include/linux/string.h b/tools/include/linux/string.h
index 51ad3cf4fa82..ca183a0e846a 100644
--- a/tools/include/linux/string.h
+++ b/tools/include/linux/string.h
@@ -3,6 +3,7 @@
#define _TOOLS_LINUX_STRING_H_
#include <linux/types.h> /* for size_t */
+#include <sys/types.h> /* for ssize_t */
#include <string.h>
void *memdup(const void *src, size_t len);
@@ -12,7 +13,7 @@ void argv_free(char **argv);
int strtobool(const char *s, bool *res);
-#define strscpy strcpy
+ssize_t strscpy(char *dest, const char *src, size_t count);
/*
* glibc based builds needs the extern while uClibc doesn't.
diff --git a/tools/lib/string.c b/tools/lib/string.c
index 3126d2cff716..54c9163fa2b0 100644
--- a/tools/lib/string.c
+++ b/tools/lib/string.c
@@ -239,3 +239,17 @@ void *memchr_inv(const void *start, int c, size_t bytes)
return check_bytes8(start, value, bytes % 8);
}
+
+ssize_t strscpy(char *dst, const char *src, size_t count)
+{
+ size_t len;
+
+ if (count == 0)
+ return -E2BIG;
+
+ len = strnlen(src, count - 1);
+ memcpy(dst, src, len);
+ dst[len] = '\0';
+
+ return src[len] ? -E2BIG : len;
+}
next prev parent reply other threads:[~2026-02-19 1:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-18 0:30 [PATCH bpf v2 00/15] selftests/bpf: Fixes for userspace ASAN Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 01/15] selftests/bpf: Pass through build flags to bpftool and resolve_btfids Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 02/15] resolve_btfids: Fix memory leaks reported by ASAN Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 03/15] selftests/bpf: Add DENYLIST.asan Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 04/15] selftests/bpf: Refactor bpf_get_ksyms() trace helper Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 05/15] selftests/bpf: Fix memory leaks in tests Ihor Solodrai
2026-02-19 23:58 ` Eduard Zingerman
2026-02-18 0:30 ` [PATCH bpf v2 06/15] selftests/bpf: Fix cleanup in check_fd_array_cnt__fd_array_too_big() Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 07/15] veristat: Fix a memory leak for preset ENUMERATOR Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 08/15] selftests/bpf: Fix use-after-free in xdp_metadata test Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 09/15] selftests/bpf: Fix double thread join in uprobe_multi_test Ihor Solodrai
2026-02-18 17:54 ` Ihor Solodrai
2026-02-18 18:47 ` Mykyta Yatsenko
2026-02-22 22:18 ` [PATCH bpf v2 09/15] selftests/bpf: Fix double thread join in uprobe_multi_testg Jiri Olsa
2026-02-18 0:30 ` [PATCH bpf v2 10/15] selftests/bpf: Fix resource leaks caused by missing cleanups Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 11/15] selftests/bpf: Free bpf_object in test_sysctl Ihor Solodrai
2026-02-20 0:08 ` Eduard Zingerman
2026-02-18 0:30 ` [PATCH bpf v2 12/15] selftests/bpf: Fix array bounds warning in jit_disasm_helpers Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 13/15] selftests/bpf: Fix out-of-bounds array access bugs reported by ASAN Ihor Solodrai
2026-02-18 0:30 ` [PATCH bpf v2 14/15] selftests/bpf: Check BPFTOOL env var in detect_bpftool_path() Ihor Solodrai
2026-02-18 16:44 ` Mykyta Yatsenko
2026-02-18 17:38 ` Alexei Starovoitov
2026-02-18 18:17 ` Ihor Solodrai
2026-02-19 1:12 ` Ihor Solodrai [this message]
2026-02-19 1:39 ` Alexei Starovoitov
2026-02-18 0:30 ` [PATCH bpf v2 15/15] selftests/bpf: Don't override SIGSEGV handler with ASAN Ihor Solodrai
2026-02-18 15:12 ` Mykyta Yatsenko
2026-02-20 0:36 ` Eduard Zingerman
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=54cffd1f-df2f-4a01-a07d-0509425558d9@linux.dev \
--to=ihor.solodrai@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=alexis.lothore@bootlin.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olsajiri@gmail.com \
--cc=yatsenko@meta.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.