All of lore.kernel.org
 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 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.