From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9E79E33E5 for ; Wed, 27 Apr 2022 18:53:52 +0000 (UTC) Received: by mail-io1-f48.google.com with SMTP id 125so4211632iov.10 for ; Wed, 27 Apr 2022 11:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VJ91s6H07ClEByjQbgZruheBlPpsvHRlP6vfpPqzZKY=; b=EKwxHil5G0kU+wbkmov0G1EaEobARTaBhSglDRm/pqjMlzyw2xWvkwLpGcmiuCwiWJ At36hRwRARLjFsB0PsstrYFE9MGEZmMhqVj6IkdW1Qe3i77MufwhagvCIO3pyldfedH+ 1L5FME3HrT5gXe+YfTuK1vScwvVdBBAvF3r85wZ4RSEairsG6Sl93FEnp+wFW9Lub42h JoeSUxM+XtEzDhZiGXt0UT79mhVEXx13upi3pSqqFpUs393Ub5H4TEiurTeKxrq4SzOx bx8DqZf4u4eSuipwPj4ZXSXZxkJ0PDwLmP82YCvAND/nMeSjVzccZu1gkgmHm97aBOf9 qsLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VJ91s6H07ClEByjQbgZruheBlPpsvHRlP6vfpPqzZKY=; b=kSJg/k2tELWb4jjfSynBMHGILyYKUBFA+z2oGGmdZtZyPwVzsBk5m5eEgPtuDy4HWp HIvg1XJeEGv+V+J7GmnESUjmE+DlRbjd79YsmFZ8WCxpyRb1FScT5D+CWkaMhaY4wk67 2aIFKGjEmTaVSe7S+cd5jn26HH48j7EEr7hsDPDx7ng0b8k0/2n+3WUwLhX3F1UfysRB hN19oWN8SIgCuYV7oN+C37T1GOP1CKh9T7hp5+Fnmu94JiY+gUxFEW6ofPFcTJELKYtJ RpL1P9cYlFnLkU3z+Lvp6Gwi2TNS+KToIUtsXcob68AdCK1jqYpFv+HUrGl5YNtRVz6/ hAEA== X-Gm-Message-State: AOAM531vxOH6P36VP+mX72K3gpSr+YyzcUYSIV+yB9HZGCNmyH7wia3G tI9TtRc7hxl3yrL/yyxqw1xhhBO2Ta5j0jEl+ow= X-Google-Smtp-Source: ABdhPJzl9VUnx3Oh6fY4dpfEp3sorFTDo26fFd33NZFaIoxLMKHh9xEeNMXVp8dcrjOJt836MeA+18nprDrk4z78Bj8= X-Received: by 2002:a5d:9f4e:0:b0:652:2323:2eb8 with SMTP id u14-20020a5d9f4e000000b0065223232eb8mr12051724iot.79.1651085631636; Wed, 27 Apr 2022 11:53:51 -0700 (PDT) Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20220414223704.341028-1-alobakin@pm.me> <20220414223704.341028-9-alobakin@pm.me> <05d21d85-7b59-a8f9-73dc-89189986db11@fb.com> In-Reply-To: <05d21d85-7b59-a8f9-73dc-89189986db11@fb.com> From: Andrii Nakryiko Date: Wed, 27 Apr 2022 11:53:40 -0700 Message-ID: Subject: Re: [PATCH bpf-next 08/11] samples: bpf: fix shifting unsigned long by 32 positions To: Yonghong Song Cc: Alexander Lobakin , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Martin KaFai Lau , Song Liu , John Fastabend , KP Singh , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Jonathan Lemon , Nathan Chancellor , Nick Desaulniers , Dmitrii Dolgov <9erthalion6@gmail.com>, Quentin Monnet , Tiezhu Yang , Kumar Kartikeya Dwivedi , Chenbo Feng , Willem de Bruijn , Daniel Wagner , Thomas Graf , Ong Boon Leong , "linux-perf-use." , open list , Networking , bpf , llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" On Wed, Apr 27, 2022 at 8:55 AM Yonghong Song wrote: > > > > On 4/20/22 10:18 AM, Andrii Nakryiko wrote: > > On Thu, Apr 14, 2022 at 3:46 PM Alexander Lobakin wrote: > >> > >> On 32 bit systems, shifting an unsigned long by 32 positions > >> yields the following warning: > >> > >> samples/bpf/tracex2_kern.c:60:23: warning: shift count >= width of type [-Wshift-count-overflow] > >> unsigned int hi = v >> 32; > >> ^ ~~ > >> > > > > long is always 64-bit in BPF, but I suspect this is due to > > samples/bpf/Makefile still using this clang + llc combo, where clang > > is called with native target and llc for -target bpf. Not sure if we > > are ready to ditch that complicated combination. Yonghong, do we still > > need that or can we just use -target bpf in samples/bpf? > > Current most bpf programs in samples/bpf do not use vmlinux.h and CO-RE. > They direct use kernel header files. That is why clang C -> IR > compilation still needs to be native. > > We could just use -target bpf for the whole compilation but that needs > to change the code to use vmlinux.h and CO-RE. There are already a > couple of sample bpf programs did this. Right, I guess I'm proposing to switch samples/bpf to vmlinux.h. Only purely networking BPF apps can get away with not using vmlinux.h because they might avoid dependency on kernel types. But even then a lot of modern networking apps seem to be gaining elements of more generic tracing and would rely on CO-RE for staying "portable" between kernels. So it might be totally fine to just use CO-RE universally in samples/bpf? > > > > > > >> The usual way to avoid this is to shift by 16 two times (see > >> upper_32_bits() macro in the kernel). Use it across the BPF sample > >> code as well. > >> > >> Fixes: d822a1926849 ("samples/bpf: Add counting example for kfree_skb() function calls and the write() syscall") > >> Fixes: 0fb1170ee68a ("bpf: BPF based latency tracing") > >> Fixes: f74599f7c530 ("bpf: Add tests and samples for LWT-BPF") > >> Signed-off-by: Alexander Lobakin > >> --- > >> samples/bpf/lathist_kern.c | 2 +- > >> samples/bpf/lwt_len_hist_kern.c | 2 +- > >> samples/bpf/tracex2_kern.c | 2 +- > >> 3 files changed, 3 insertions(+), 3 deletions(-) > >> > > > > [...]