From nobody Wed Dec 17 23:53:50 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78740C77B72 for ; Mon, 17 Apr 2023 08:45:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230033AbjDQIp0 (ORCPT ); Mon, 17 Apr 2023 04:45:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230497AbjDQIpX (ORCPT ); Mon, 17 Apr 2023 04:45:23 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AE3330E8 for ; Mon, 17 Apr 2023 01:44:57 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id kh6so23275099plb.0 for ; Mon, 17 Apr 2023 01:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1681721097; x=1684313097; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=NmX+x9DqsXNcwyQ2AzQA++eNv/lGS7QxnupRL+FL2+k=; b=Wv8kL57awpXRXk0EW9fQQUFcNJ2J/nff5Thkeftm3tWKRmEgFD+RBldf1zyEBEDkmA 46rwpDSM9A7x7dtso8ZBruxf9fz4B3RvcOL0Yokk/WSyECsf5Gns1EX/jQqJZDnZMtxB OkVXxFKhz9GwTWW6H13EtmWHN+qWm/YucyMBCv+PVzsDWicc22sOuZrmL18ZADCRZ58z dqnYkrjeddOp7rPSVJgixl0pVjPJ8Z4rfB4KpXJrJyTwJiTnxpyKuxZ7rZhghUT9k3N1 JMSqElLyhb/Sa6Mvwt/GQQ2hbwqSd9+eLfkJw6rNUBrc+HwlmnhtMASXw4U/CM6Y7xxQ t/Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681721097; x=1684313097; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NmX+x9DqsXNcwyQ2AzQA++eNv/lGS7QxnupRL+FL2+k=; b=a89yHyX/V6nWFLnaT4o+aObTifM5wggoEGNkgxtVkNFXszS22IBWITGtXUD70/R9pD +ABTY/I/hsjAcQ3GrgUrGZ53DMovMtnQu7JhuFVGLzJu4vv87qeNFfl9UjC4SoiJ72aS YuZvPRyWNTkIhMEE/vA42eEY/rK1n1yPIl9M9j7E8fAhKwk1VQzs5OaeiXAiYRTv79yy LV+16GHjwszuwCEacCZ4AigRAdKDL0Apnm3BVpEnaBiqAlE429ZZCaB1EC6nD6pAG5gU /AwwxHGd2Drhr4lr6KDvIovF0xK9qp+tGgbrYWKV9pUAvTF7VFCbU6XTFRQL/f21Q2K1 qdCQ== X-Gm-Message-State: AAQBX9ehdY9oNvLUAvtP4OxS2N1gRQIHePSq1bWMDv4tjCWv2jt2qY0p 6DQdpfuRYVXaSEz7M6lnhjXE X-Google-Smtp-Source: AKy350a5zEFkTizr11zAP8X9j+v5+H2omsRZxk1T4qjyH/MeZJDIN2agaSCVBBv1gbyuRPQ/1AF77A== X-Received: by 2002:a05:6a20:12c6:b0:ef:f558:b80 with SMTP id v6-20020a056a2012c600b000eff5580b80mr2234565pzg.58.1681721097130; Mon, 17 Apr 2023 01:44:57 -0700 (PDT) Received: from HX3YDL60GM.bytedance.net ([139.177.225.243]) by smtp.gmail.com with ESMTPSA id u17-20020aa78491000000b0063ba9108c5csm1571536pfn.149.2023.04.17.01.44.54 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 17 Apr 2023 01:44:56 -0700 (PDT) From: "songrui.771" To: Andrii Nakryiko , Alexei Starovoitov , Daniel Borkmann Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org, "songrui.771" Subject: [PATCH] libbpf: correct the macro KERNEL_VERSION for old kernel Date: Mon, 17 Apr 2023 16:44:49 +0800 Message-Id: <20230417084449.99848-1-songrui.771@bytedance.com> X-Mailer: git-send-email 2.39.2 (Apple Git-143) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The introduced header file linux/version.h in libbpf_probes.c may have a wrong macro KERNEL_VERSION for calculating LINUX_VERSION_CODE in some old kernel (Debian9, 10). Below is a version info example from Debian 10. release: 4.19.0-22-amd64 version: #1 SMP Debian 4.19.260-1 (2022-09-29) The macro KERNEL_VERSION is defined to (((a) << 16) + ((b) << 8)) + (c)), which a, b, and c stand for major, minor and patch version. So in example h= ere, the major is 4, minor is 19, patch is 260, the LINUX_VERSION(4, 19, 260) wh= ich is 267268 should be matched to LINUX_VERSION_CODE. However, the KERNEL_VERS= ION_CODE in linux/version.h is defined to 267263. I noticed that the macro KERNEL_VERSION in linux/version.h of some new kern= el is defined to (((a) << 16) + ((b) << 8) + ((c) > 255 ? 255 : (c))). And KERNEL_VERSION(4, 19, 260) is equal to 267263 which is the right LINUX_VERS= ION_CODE. The mismatched LINUX_VERSION_CODE which will cause failing to load kprobe B= PF programs in the version check of BPF syscall. The return value of get_kernel_version in libbpf_probes.c should be matched= to LINUX_VERSION_CODE by correcting the macro KERNEL_VERSION. Signed-off-by: songrui.771 --- tools/lib/bpf/libbpf_probes.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/tools/lib/bpf/libbpf_probes.c b/tools/lib/bpf/libbpf_probes.c index 4f3bc968ff8e..5b22a880c7e7 100644 --- a/tools/lib/bpf/libbpf_probes.c +++ b/tools/lib/bpf/libbpf_probes.c @@ -18,6 +18,10 @@ #include "libbpf.h" #include "libbpf_internal.h" =20 +#ifndef LIBBPF_KERNEL_VERSION +#define LIBBPF_KERNEL_VERSION(a, b, c) (((a) << 16) + ((b) << 8) + ((c) > = 255 ? 255 : (c))) +#endif + /* On Ubuntu LINUX_VERSION_CODE doesn't correspond to info.release, * but Ubuntu provides /proc/version_signature file, as described at * https://ubuntu.com/kernel, with an example contents below, which we @@ -47,7 +51,7 @@ static __u32 get_ubuntu_kernel_version(void) if (ret !=3D 3) return 0; =20 - return KERNEL_VERSION(major, minor, patch); + return LIBBPF_KERNEL_VERSION(major, minor, patch); } =20 /* On Debian LINUX_VERSION_CODE doesn't correspond to info.release. @@ -74,7 +78,7 @@ static __u32 get_debian_kernel_version(struct utsname *in= fo) if (sscanf(p, "Debian %u.%u.%u", &major, &minor, &patch) !=3D 3) return 0; =20 - return KERNEL_VERSION(major, minor, patch); + return LIBBPF_KERNEL_VERSION(major, minor, patch); } =20 __u32 get_kernel_version(void) @@ -97,7 +101,7 @@ __u32 get_kernel_version(void) if (sscanf(info.release, "%u.%u.%u", &major, &minor, &patch) !=3D 3) return 0; =20 - return KERNEL_VERSION(major, minor, patch); + return LIBBPF_KERNEL_VERSION(major, minor, patch); } =20 static int probe_prog_load(enum bpf_prog_type prog_type, --=20 2.39.2 (Apple Git-143)