On 11/25/21 11:21 PM, Daniel Borkmann wrote:
On 11/24/21 1:23 AM, Andrii Nakryiko wrote:Integer overflow is intentional, silence the sanitizer. It works completely reliably on sane compilers and architectures. Signed-off-by: Andrii Nakryiko <andrii@xxxxxxxxxx> --- tools/lib/bpf/btf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c index 8024fe355ca8..be1dafd56a13 100644 --- a/tools/lib/bpf/btf.c +++ b/tools/lib/bpf/btf.c @@ -3127,6 +3127,7 @@ struct btf_dedup { struct strset *strs_set; }; +__attribute__((no_sanitize("signed-integer-overflow"))) static long hash_combine(long h, long value) { return h * 31 + value;Sgtm, I guess my only question, was there a reason for not using e.g. __u64 in the first place? Meaning, __u64 hash_combine(__u64 h, __u64 value) plus the call-sites where you have h variable re-feeding into hash_combine().
Given the remainder of the series is all straight forward, I took that in already, but would still be nice if we can silence the sanitizer complaint w/o such attribute workaround. Thanks, Daniel
