From: Shuah Khan <skhan@linuxfoundation.org> To: Kees Cook <keescook@chromium.org> Cc: shuah@kernel.org, luto@amacapital.net, wad@chromium.org, daniel@iogearbox.net, kafai@fb.com, yhs@fb.com, andriin@fb.com, gregkh@linuxfoundation.org, tglx@linutronix.de, khilman@baylibre.com, mpe@ellerman.id.au, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, "skh >> Shuah Khan" <skhan@linuxfoundation.org> Subject: Re: [PATCH v2 2/4] selftests: Fix seccomp to support relocatable build (O=objdir) Date: Tue, 10 Mar 2020 17:11:47 -0600 Message-ID: <d125a38f-50aa-dbf1-0fcf-59d4ad4a1441@linuxfoundation.org> (raw) In-Reply-To: <202003050937.BA14B70DEB@keescook> On 3/5/20 10:42 AM, Kees Cook wrote: > On Thu, Mar 05, 2020 at 09:41:34AM -0700, Shuah Khan wrote: >> On 3/4/20 7:20 PM, Kees Cook wrote: >>> Instead of the TEST_CUSTOM_PROGS+all dance, you can just add an explicit >>> dependency, with the final seccomp/Makefile looking like this: >>> >>> >>> # SPDX-License-Identifier: GPL-2.0 >>> CFLAGS += -Wl,-no-as-needed -Wall >>> LDFLAGS += -lpthread >>> >>> TEST_GEN_PROGS := seccomp_bpf seccomp_benchmark >>> >> >> TEST_CUSTOM_PROGS is for differentiating test programs that >> can't use lib.mk generic rules. It is appropriate to use >> for seccomp_bpf > > I don't follow? This suggested Makefile works for me (i.e. it can use > the lib.mk generic rules since CFLAGS and LDFLAGS can be customized > first, and it just adds an additional dependency). > Yeah. TEST_CUSTOM_PROGS isn't really needed for this custom case. I can refine it and get rid of the dependency. >>> include ../lib.mk >>> >>> # Additional dependencies >>> $(OUTPUT)/seccomp_bpf: ../kselftest_harness.h > > BTW, I see a lot of other targets that use kselftest_harness.h appear to > be missing this Makefile dependency, but that's a different problem. :) > >>> (Though this fails in the same way as above when run from the top-level >>> directory.) >>> >> >> I didn't see this because I have been the same directory I used >> for relocated cross-build kernel. :( >> >> Thanks for testing this. I know the problem here. all is a dependency >> for install step and $(OUTPUT) is referencing the objdir before it >> gets created. It is a Makefile/lib.mk problem to fix. >> I was way off with my analysis. :( >> I will do a separate patch for this. This will show up in any test >> that is using $(OUTPUT) to relocate objects mainly the ones that >> require custom build rule like seeccomp. > > Okay, cool. It looked to me like it lost track of the top level source > directory (i.e. "make: entering $output" ... "can't find > ../other/files") > Odd that you would have empty objdir in the cross-compile case. In the cross-compile case, you would have cross-built kernel first in the object directory. Your objdir won't be empty. This is no different from kselftest build dependency on kernel build even when srcdir=objdir So for cross-build case, the following is the workflow to build kernel first and then the tests: make O=/../objdir ARCH=arm64 HOSTCC=gcc CROSS_COMPILE=aarch64-linux-gnu- defconfig make O=/../objdir ARCH=arm64 HOSTCC=gcc CROSS_COMPILE=aarch64-linux-gnu- all make kselftest-install O=/../objdir ARCH=arm64 HOSTCC=gcc CROSS_COMPILE=aarch64-linux-gnu- TARGETS=seccomp You can isolate a single test when you are do native build: make kselftest-install O=/../objdir TARGETS=seccomp The above won't fail even if objdir doesn't exist and/or empty. thanks, -- Shuah
prev parent reply index Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-05 0:36 Shuah Khan 2020-03-05 2:20 ` Kees Cook 2020-03-05 16:41 ` Shuah Khan 2020-03-05 17:42 ` Kees Cook 2020-03-10 23:11 ` Shuah Khan [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=d125a38f-50aa-dbf1-0fcf-59d4ad4a1441@linuxfoundation.org \ --to=skhan@linuxfoundation.org \ --cc=andriin@fb.com \ --cc=bpf@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=gregkh@linuxfoundation.org \ --cc=kafai@fb.com \ --cc=keescook@chromium.org \ --cc=khilman@baylibre.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mpe@ellerman.id.au \ --cc=netdev@vger.kernel.org \ --cc=shuah@kernel.org \ --cc=tglx@linutronix.de \ --cc=wad@chromium.org \ --cc=yhs@fb.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ linux-kernel@vger.kernel.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git