[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jLLAE7H37Ug+vFJ42gv5gOV1mc28BMVQeiP_kkkodjsSw@mail.gmail.com>
Date: Tue, 10 Jul 2018 08:19:18 -0700
From: Kees Cook <keescook@...omium.org>
To: Dirk Gouders <dirk@...ders.net>
Cc: Masahiro Yamada <yamada.masahiro@...ionext.com>,
linux-kbuild <linux-kbuild@...r.kernel.org>,
Ulf Magnusson <ulfalizer@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Sam Ravnborg <sam@...nborg.org>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH v3 05/12] kconfig: make syncconfig update .config
regardless of sym_change_count
On Mon, Jul 9, 2018 at 4:39 AM, Dirk Gouders <dirk@...ders.net> wrote:
> I think, I solved the puzzle and perhaps, that saves others some time:
>
> The problem is that "if_changed" was not designed for multiple use
> inside a recipe and in the case of compressed/vmlinux, the 2-fold use
> created a kind of flip-flop for situations when nothing has to be done
> to build the target.
>
> Because each of the two users of "if_changed" stores it's footprint in
> .vmlinux.cmd but that file then isn't re-read, one of the two
> "if_changed" calculates that nothing has to be done wheras the other one
> recognizes a change in the commandline, because it sees the command-line
> for the other part of the reciepe.
Ooh, nice find. Thanks for debugging this!
> In the next make, the roles flip, because the previously satisfied
> "if_changed" now sees the command-line of the other one. And so on...
>
> I am not a Kbuild expert but the attached patch fixes that problem by
> introducing "if_changed_multi" that accepts two commands -- one whose
> commandline should be checked and a second one that should be
> executed.
>
> Dirk
>
>
> diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
> index fa42f895fdde..f39822fca994 100644
> --- a/arch/x86/boot/compressed/Makefile
> +++ b/arch/x86/boot/compressed/Makefile
> @@ -107,8 +107,8 @@ define cmd_check_data_rel
> endef
>
> $(obj)/vmlinux: $(vmlinux-objs-y) FORCE
> - $(call if_changed,check_data_rel)
> - $(call if_changed,ld)
> + $(call if_changed_multi,ld,check_data_rel)
> + $(call if_changed_multi,ld,ld)
This does seem to do the right thing, but mainly because arg1 is what
actually writes vmlinux, which seems a bit fragile here.
However, the combination is "if_changed" with the "FORCE". This is to
make sure the command line is evaluated in addition to the build deps.
The check_data_rel isn't as sensitive, so maybe the right solution is
just:
-$(obj)/vmlinux: $(vmlinux-objs-y) FORCE
- $(call if_changed,check_data_rel)
+$(obj)/vmlinux:: $(vmlinux-objs-y)
+ $(call cmd,check_data_rel)
+$(obj)/vmlinux:: $(vmlinux-objs-y) FORCE
$(call if_changed,ld)
Then check_data_rel is only evaluated with when the deps change (no
FORCE nor if_changed needed), and doesn't interfere with the "ld"
call?
Regardless, the docs for if_changed should be updated to explicitly
mention it should only be called once per target.
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists