All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sidong Yang <sidong.yang@furiosa.ai>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] libbpf: Change hash_combine parameters from long to __u32
Date: Sat, 16 Nov 2024 09:36:01 +0900	[thread overview]
Message-ID: <Zzfo8YCeNkbCQDTg@sidongui-MacBookPro.local> (raw)
In-Reply-To: <CAEf4BzYape9gtc7k1NQMD5BrfakzDXV_9SHNqZeamcaSKn744Q@mail.gmail.com>

On Fri, Nov 15, 2024 at 11:57:24AM -0800, Andrii Nakryiko wrote:
> On Fri, Nov 15, 2024 at 2:51 AM Sidong Yang <sidong.yang@furiosa.ai> wrote:
> >
> > The hash_combine() could be trapped when compiled with sanitizer like "zig cc".
> > This patch changes parameters to __u32 to fix it.
> 
> Can you please elaborate? What exactly are you fixing? "Undefined"
> signed integer overflow? I can consider changing long to unsigned
> long, but I don't think we should downgrade from long all the way to
> 32-bit u32. I'd rather keep all those 64 bits for hash.

Hi, Andrii.

Actually I'm using libbpf-rs with maturin build that makes python package for
rust. It seems that it uses zig cc for cross compilation. It compiles libbpf
like this command.

CC="zig cc" make CFLAGS="-fsanitize-trap"

And hash_combine's result is like below.

0000000000063860 <hash_combine>:
   63860:       55                      push   %rbp
   63861:       48 89 e5                mov    %rsp,%rbp
   63864:       48 89 7d f8             mov    %rdi,-0x8(%rbp)
   63868:       48 89 75 f0             mov    %rsi,-0x10(%rbp)
   6386c:       b8 1f 00 00 00          mov    $0x1f,%eax
   63871:       48 0f af 45 f8          imul   -0x8(%rbp),%rax
   63876:       48 89 45 e8             mov    %rax,-0x18(%rbp)
   6387a:       0f 90 c0                seto   %al
   6387d:       34 ff                   xor    $0xff,%al
   6387f:       a8 01                   test   $0x1,%al
   63881:       0f 85 05 00 00 00       jne    6388c <hash_combine+0x2c>
-> 63887:       67 0f b9 40 0c          ud1    0xc(%eax),%eax
   6388c:       48 8b 45 e8             mov    -0x18(%rbp),%rax
   63890:       48 03 45 f0             add    -0x10(%rbp),%rax
   63894:       48 89 45 e0             mov    %rax,-0x20(%rbp)
   63898:       0f 90 c0                seto   %al
   6389b:       34 ff                   xor    $0xff,%al
   6389d:       a8 01                   test   $0x1,%al
   6389f:       0f 85 04 00 00 00       jne    638a9 <hash_combine+0x49>
   638a5:       67 0f b9 00             ud1    (%eax),%eax
   638a9:       48 8b 45 e0             mov    -0x20(%rbp),%rax
   638ad:       5d                      pop    %rbp
   638ae:       c3                      ret   
   638af:       90                      nop

When I'm using libbpf-rs, it receives SIGILL for ud1 instruction.
It seems more appropriate to use u64 instead of u32, doesn't it?
I'll work on it.

Thanks,
Sidong
> 
> pw-bot: cr
> 
> >
> > Signed-off-by: Sidong Yang <sidong.yang@furiosa.ai>
> > ---
> >  tools/lib/bpf/btf.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> > index 8befb8103e32..11ccb5aa4958 100644
> > --- a/tools/lib/bpf/btf.c
> > +++ b/tools/lib/bpf/btf.c
> > @@ -3548,7 +3548,7 @@ struct btf_dedup {
> >         struct strset *strs_set;
> >  };
> >
> > -static long hash_combine(long h, long value)
> > +static __u32 hash_combine(__u32 h, __u32 value)
> >  {
> >         return h * 31 + value;
> >  }
> > --
> > 2.42.0
> >
> >

  reply	other threads:[~2024-11-16  0:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-15 10:34 [RFC PATCH] libbpf: Change hash_combine parameters from long to __u32 Sidong Yang
2024-11-15 19:57 ` Andrii Nakryiko
2024-11-16  0:36   ` Sidong Yang [this message]
2024-11-16  4:39     ` Yonghong Song
2024-11-16  6:49       ` Sidong Yang

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=Zzfo8YCeNkbCQDTg@sidongui-MacBookPro.local \
    --to=sidong.yang@furiosa.ai \
    --cc=andrii.nakryiko@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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.