BPF List
 help / color / mirror / Atom feed
From: Alan Maguire <alan.maguire@oracle.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Martin KaFai Lau <kafai@fb.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, bpf <bpf@vger.kernel.org>,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] libbpf: fix str_has_sfx()
Date: Wed, 20 Jul 2022 08:37:58 +0100	[thread overview]
Message-ID: <46ca78ec-17b5-3cf1-a42d-7659563c6cf7@oracle.com> (raw)
In-Reply-To: <CAADnVQLS=asNdrmdK-jgW4AZmJih00OTvXZg_RA55wLY=bHMZg@mail.gmail.com>

On 19/07/2022 18:51, Alexei Starovoitov wrote:
> On Tue, Jul 19, 2022 at 10:19 AM Martin KaFai Lau <kafai@fb.com> wrote:
>>
>> On Tue, Jul 19, 2022 at 12:53:01PM +0300, Dan Carpenter wrote:
>>> The return from strcmp() is inverted so the it returns true instead
>>> of false and vise versa.
>>>
>>> Fixes: a1c9d61b19cb ("libbpf: Improve library identification for uprobe binary path resolution")
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>> ---
>>> Spotted during review.  *cmp() functions should always have a comparison
>>> to zero.
>>>       if (strcmp(a, b) < 0) {  <-- means a < b
>>>       if (strcmp(a, b) >= 0) { <-- means a >= b
>>>       if (strcmp(a, b) != 0) { <-- means a != b
>>> etc.
>>>
>>>  tools/lib/bpf/libbpf_internal.h | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_internal.h
>>> index 9cd7829cbe41..008485296a29 100644
>>> --- a/tools/lib/bpf/libbpf_internal.h
>>> +++ b/tools/lib/bpf/libbpf_internal.h
>>> @@ -108,9 +108,9 @@ static inline bool str_has_sfx(const char *str, const char *sfx)
>>>       size_t str_len = strlen(str);
>>>       size_t sfx_len = strlen(sfx);
>>>
>>> -     if (sfx_len <= str_len)
>>> -             return strcmp(str + str_len - sfx_len, sfx);
>>> -     return false;
>>> +     if (sfx_len > str_len)
>>> +             return false;
>>> +     return strcmp(str + str_len - sfx_len, sfx) == 0;
>> Please tag the subject with "bpf" next time.
>>
>> Acked-by: Martin KaFai Lau <kafai@fb.com>
> 
> Alan,
> 
> If it was so broken how did it work earlier?
> Do we have a test for this?
> 

We have tests for automatic path determination, yes, but those
tests specify libc.so.6, so are testing the strstr(file, ".so.") 
predicate below:

	if (str_has_sfx(file, ".so") || strstr(file, ".so.")) {

Problem is, on many systems, libc.so is a GNU ld script rather
than an actual library:

cat /usr/lib64/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a  AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )

...so we can't rely on system library .so files actually containing
the library to instrument.

Maybe we can do something with liburandom_read.so now we have it
there; I was looking at extending the auto-path determination
to usdt too, so we could add a new test to cover this then I think.

Alan

  reply	other threads:[~2022-07-20  7:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-19  9:53 [PATCH] libbpf: fix str_has_sfx() Dan Carpenter
2022-07-19 17:19 ` Martin KaFai Lau
2022-07-19 17:50   ` Dan Carpenter
2022-07-19 17:54     ` Alexei Starovoitov
2022-07-20  9:11       ` Dan Carpenter
2022-07-19 17:51   ` Alexei Starovoitov
2022-07-20  7:37     ` Alan Maguire [this message]
2022-07-28 22:10       ` Andrii Nakryiko
2022-07-21 13:00 ` patchwork-bot+netdevbpf

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=46ca78ec-17b5-3cf1-a42d-7659563c6cf7@oracle.com \
    --to=alan.maguire@oracle.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dan.carpenter@oracle.com \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=yhs@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox