From patchwork Tue Jan 26 16:13:20 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Quentin Monnet X-Patchwork-Id: 12047323 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE936C433E9 for ; Tue, 26 Jan 2021 16:16:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9E92C22DFB for ; Tue, 26 Jan 2021 16:16:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391223AbhAZQOy (ORCPT ); Tue, 26 Jan 2021 11:14:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392214AbhAZQOG (ORCPT ); Tue, 26 Jan 2021 11:14:06 -0500 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4CCFC061A29 for ; Tue, 26 Jan 2021 08:13:25 -0800 (PST) Received: by mail-ej1-x62e.google.com with SMTP id kg20so23280346ejc.4 for ; Tue, 26 Jan 2021 08:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isovalent-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=uYjhI9Zs729gEk72NbctUgKe2hbWHlrBlwkbt1TwJow=; b=W+h7X+uus9hJKu8qXg9P1U4DIto5ByGHdTbf+NTfA4ES20D2WbTr0MWpYbi2vzIX+6 fVnxPcEM72PL5UuketJW8f5NbFOWvju6O0aerbXl+6TIgKOCRFp0GonoDuaHVEZizve/ j1gMnJ2pTGwfUoUVA3pv2F+aB6yreT3NNTamEFDzwkQqjFI7HtXv9s6hsn2oWDlcYpkr 0R+SnR+7RCzdaEbZ9q6aa433uBvaa3RfSsL0NAVDYKysQ1u/dwin9gS9ruuYbTWmlhmQ Vw37iCZ0co4Brc6Elcf2qyfr+oU5OQflhOBIeeSB9J8FIfeDKgHM5AnJTzb5iRm5etB+ 0aqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=uYjhI9Zs729gEk72NbctUgKe2hbWHlrBlwkbt1TwJow=; b=rbFKeZCbPtVbwc+hl5Zmy3NqMSTU568oB4ftsLQxs7+i4RVgqj67YvTK0ZnLcUgPmh 8Me4SPe6Yw2txgQpK0DY7pCUDHUt8rG7tQaVvnsxVXM5qyzIfYoSVtJ3RsZ09QMYCjtt M4GzlXYqk2dQP31NNW7Rsvx6qZivVp8C45hozvUL3MRLdcNouSIinNa4KohajJDjNdM7 uRCf+CF3BEdY/GNJCf+KN1gC4cNdQEjOHbG0p6VqCkOL9zH0T3CKMsOIZHH8AsZkMVIC qSZbLWY3EUaZTm5KUYdyj9jhqnEd32M8HFoGEjrV4IDyelDr7GbtHftB/EDyQ3dzJ5aH AGUQ== X-Gm-Message-State: AOAM533EIal87pVVv3ydnY2RQtvLREPbJMCQMdxzG/ktUzQKIP28QUOI ZTO/HnxLnmj3OWAW7SCc1am9Nw== X-Google-Smtp-Source: ABdhPJznhk70RsoMMkEfODd7T5VGUlA0+gOKPb2sl0nJ4IT0dMXY9P0b8jHPqT3GEnXmc2xpBNhclw== X-Received: by 2002:a17:906:48f:: with SMTP id f15mr3991893eja.392.1611677604418; Tue, 26 Jan 2021 08:13:24 -0800 (PST) Received: from localhost.localdomain ([194.35.116.76]) by smtp.gmail.com with ESMTPSA id dd27sm12804927edb.23.2021.01.26.08.13.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Jan 2021 08:13:23 -0800 (PST) From: Quentin Monnet To: Alexei Starovoitov , Daniel Borkmann Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, Quentin Monnet , Andrii Nakryiko , Brendan Higgins , David Gow , Masahiro Yamada Subject: [PATCH bpf v2] bpf: fix build for BPF preload when $(O) points to a relative path Date: Tue, 26 Jan 2021 16:13:20 +0000 Message-Id: <20210126161320.24561-1-quentin@isovalent.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org X-Patchwork-Delegate: bpf@iogearbox.net Building the kernel with CONFIG_BPF_PRELOAD, and by providing a relative path for the output directory, may fail with the following error: $ make O=build bindeb-pkg ... /.../linux/tools/scripts/Makefile.include:5: *** O=build does not exist. Stop. make[7]: *** [/.../linux/kernel/bpf/preload/Makefile:9: kernel/bpf/preload/libbpf.a] Error 2 make[6]: *** [/.../linux/scripts/Makefile.build:500: kernel/bpf/preload] Error 2 make[5]: *** [/.../linux/scripts/Makefile.build:500: kernel/bpf] Error 2 make[4]: *** [/.../linux/Makefile:1799: kernel] Error 2 make[4]: *** Waiting for unfinished jobs.... In the case above, for the "bindeb-pkg" target, the error is produced by the "dummy" check in Makefile.include, called from libbpf's Makefile. This check changes directory to $(PWD) before checking for the existence of $(O). But at this step we have $(PWD) pointing to "/.../linux/build", and $(O) pointing to "build". So the Makefile.include tries in fact to assert the existence of a directory named "/.../linux/build/build", which does not exist. Note that the error does not occur for all make targets and architectures combinations. This was observed on x86 for "bindeb-pkg", or for a regular build for UML [0]. Here are some details. The root Makefile recursively calls itself once, after changing directory to $(O). The content for the variable $(PWD) is preserved across recursive calls to make, so it is unchanged at this step. For "bindeb-pkg", $(PWD) is eventually updated because the target writes a new Makefile (as debian/rules) and calls it indirectly through dpkg-buildpackage. This script does not preserve $(PWD), which is reset to the current working directory when the target in debian/rules is called. Although not investigated, it seems likely that something similar causes UML to change its value for $(PWD). Non-trivial fixes could be to remove the use of $(PWD) from the "dummy" check, or to make sure that $(PWD) and $(O) are preserved or updated to always play well and form a valid $(PWD)/$(O) path across the different targets and architectures. Instead, we take a simpler approach and just update $(O) when calling libbpf's Makefile, so it points to an absolute path which should always resolve for the "dummy" check run (through includes) by that Makefile. David Gow previously posted a slightly different version of this patch as a RFC [0], two months ago or so. [0] https://lore.kernel.org/bpf/20201119085022.3606135-1-davidgow@google.com/t/#u v2: Use $(LIBBPF_OUT) instead of $(abspath .), and improve commit log Cc: Andrii Nakryiko Cc: Brendan Higgins Cc: David Gow Cc: Masahiro Yamada Reported-by: David Gow Signed-off-by: Quentin Monnet --- kernel/bpf/preload/Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/preload/Makefile b/kernel/bpf/preload/Makefile index 23ee310b6eb4..1951332dd15f 100644 --- a/kernel/bpf/preload/Makefile +++ b/kernel/bpf/preload/Makefile @@ -4,8 +4,11 @@ LIBBPF_SRCS = $(srctree)/tools/lib/bpf/ LIBBPF_A = $(obj)/libbpf.a LIBBPF_OUT = $(abspath $(obj)) +# Although not in use by libbpf's Makefile, set $(O) so that the "dummy" test +# in tools/scripts/Makefile.include always succeeds when building the kernel +# with $(O) pointing to a relative path, as in "make O=build bindeb-pkg". $(LIBBPF_A): - $(Q)$(MAKE) -C $(LIBBPF_SRCS) OUTPUT=$(LIBBPF_OUT)/ $(LIBBPF_OUT)/libbpf.a + $(Q)$(MAKE) -C $(LIBBPF_SRCS) O=$(LIBBPF_OUT)/ OUTPUT=$(LIBBPF_OUT)/ $(LIBBPF_OUT)/libbpf.a userccflags += -I $(srctree)/tools/include/ -I $(srctree)/tools/include/uapi \ -I $(srctree)/tools/lib/ -Wno-unused-result