bpf: fix build for BPF preload when $(O) points to a relative path

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.

By contrast, other tools called from the main Linux Makefile get the
variable set to $(abspath $(objtree)), where $(objtree) is ".". We can
update the Makefile for kernel/bpf/preload to set $(O) to the same
value, to permit compiling with a relative path for output. Note that
apart from the Makefile.include, the variable $(O) is not used in
libbpf's build system.

Note that the error does not occur for all make targets and
architectures combinations.

- On x86, "make O=build vmlinux" appears to work fine.
  $(PWD) points to "/.../linux/tools", but $(O) points to the absolute
  path "/.../linux/build" and the test succeeds.
- On UML, it has been reported to fail with a message similar to the
  above (see [0]).
- On x86, "make O=build bindeb-pkg" fails, as described above.

It is unsure where the different values for $(O) and $(PWD) come from
(likely some recursive make with different arguments at some point), and
because several targets are broken, it feels safer to fix the $(O) value
passed to libbpf rather than to hunt down all changes to the variable.

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

Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Brendan Higgins <brendanhiggins@google.com>
Cc: David Gow <davidgow@google.com>
Reported-by: David Gow <davidgow@google.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
---
 kernel/bpf/preload/Makefile | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

On Mon, Jan 25, 2021 at 11:49 PM Quentin Monnet <quentin@isovalent.com> wrote:
>
> 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.
>
> By contrast, other tools called from the main Linux Makefile get the
> variable set to $(abspath $(objtree)), where $(objtree) is ".". We can
> update the Makefile for kernel/bpf/preload to set $(O) to the same
> value, to permit compiling with a relative path for output. Note that
> apart from the Makefile.include, the variable $(O) is not used in
> libbpf's build system.
>
> Note that the error does not occur for all make targets and
> architectures combinations.
>
> - On x86, "make O=build vmlinux" appears to work fine.
>   $(PWD) points to "/.../linux/tools", but $(O) points to the absolute
>   path "/.../linux/build" and the test succeeds.
> - On UML, it has been reported to fail with a message similar to the
>   above (see [0]).
> - On x86, "make O=build bindeb-pkg" fails, as described above.
>
> It is unsure where the different values for $(O) and $(PWD) come from
> (likely some recursive make with different arguments at some point), and
> because several targets are broken, it feels safer to fix the $(O) value
> passed to libbpf rather than to hunt down all changes to the variable.
>
> 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
>
> Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> Cc: Brendan Higgins <brendanhiggins@google.com>
> Cc: David Gow <davidgow@google.com>
> Reported-by: David Gow <davidgow@google.com>
> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
> ---

Thanks for following up on this. I've tested it against my usecase
(allyesconfig with ARCH=um), and it fixes the issue nicely.

Tested-by: David Gow <davidgow@google.com>

While I tend to agree it'd be nicer to track down the place $(O) and
$(PWD) are broken, too, given that there seem to be a number of
different ways to trigger this (bindeb-pkg and ARCH=um), I'm not sure
there's only one breakage to find.

Cheers,
-- David