[1/3] um: fix parallel building with O= option

Randy Dunlap reports UML occasionally fails to build with -j<N> and
O=<builddir> options.

  make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64'
    UPD     include/generated/uapi/linux/version.h
    WRAP    arch/x86/include/generated/asm/dma-contiguous.h
    WRAP    arch/x86/include/generated/asm/export.h
    WRAP    arch/x86/include/generated/asm/early_ioremap.h
    WRAP    arch/x86/include/generated/asm/mcs_spinlock.h
    WRAP    arch/x86/include/generated/asm/mm-arch-hooks.h
    WRAP    arch/x86/include/generated/uapi/asm/bpf_perf_event.h
    WRAP    arch/x86/include/generated/uapi/asm/poll.h
    GEN     ./Makefile
  make[2]: *** No rule to make target 'archheaders'.  Stop.
  arch/um/Makefile:119: recipe for target 'archheaders' failed
  make[1]: *** [archheaders] Error 2
  make[1]: *** Waiting for unfinished jobs....
    UPD     include/config/kernel.release
  make[1]: *** wait: No child processes.  Stop.
  Makefile:146: recipe for target 'sub-make' failed
  make: *** [sub-make] Error 2

The cause of the problem is the use of '$(MAKE) KBUILD_SRC=',
which recurses to the top Makefile via the $(objtree)/Makefile
generated by scripts/mkmakefile.

When you run "make -j<N> O=<builddir> ARCH=um", Make can execute
'archheaders' and 'outputmakefile' targets simultaneously because
there is no dependency between them.

If it happens,

  $(Q)$(MAKE) KBUILD_SRC= ARCH=$(HEADER_ARCH) archheaders

... tries to run $(objtree)/Makefile that is being updated.

The correct way for the recursion is

  $(Q)$(MAKE) -f $(srctree)/Makefile ARCH=$(HEADER_ARCH) archheaders

..., which does not rely on the generated Makefile.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

---

 arch/um/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.7.4

2018-08-04 13:47 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> Randy Dunlap reports UML occasionally fails to build with -j<N> and

> O=<builddir> options.

>

>   make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64'

>     UPD     include/generated/uapi/linux/version.h

>     WRAP    arch/x86/include/generated/asm/dma-contiguous.h

>     WRAP    arch/x86/include/generated/asm/export.h

>     WRAP    arch/x86/include/generated/asm/early_ioremap.h

>     WRAP    arch/x86/include/generated/asm/mcs_spinlock.h

>     WRAP    arch/x86/include/generated/asm/mm-arch-hooks.h

>     WRAP    arch/x86/include/generated/uapi/asm/bpf_perf_event.h

>     WRAP    arch/x86/include/generated/uapi/asm/poll.h

>     GEN     ./Makefile

>   make[2]: *** No rule to make target 'archheaders'.  Stop.

>   arch/um/Makefile:119: recipe for target 'archheaders' failed

>   make[1]: *** [archheaders] Error 2

>   make[1]: *** Waiting for unfinished jobs....

>     UPD     include/config/kernel.release

>   make[1]: *** wait: No child processes.  Stop.

>   Makefile:146: recipe for target 'sub-make' failed

>   make: *** [sub-make] Error 2

>

> The cause of the problem is the use of '$(MAKE) KBUILD_SRC=',

> which recurses to the top Makefile via the $(objtree)/Makefile

> generated by scripts/mkmakefile.

>

> When you run "make -j<N> O=<builddir> ARCH=um", Make can execute

> 'archheaders' and 'outputmakefile' targets simultaneously because

> there is no dependency between them.

>

> If it happens,

>

>   $(Q)$(MAKE) KBUILD_SRC= ARCH=$(HEADER_ARCH) archheaders

>

> ... tries to run $(objtree)/Makefile that is being updated.

>

> The correct way for the recursion is

>

>   $(Q)$(MAKE) -f $(srctree)/Makefile ARCH=$(HEADER_ARCH) archheaders

>

> ..., which does not rely on the generated Makefile.

>




I forgot to add this:

Reported-by: Randy Dunlap <rdunlap@infradead.org>




> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

> ---

>

>  arch/um/Makefile | 3 +--

>  1 file changed, 1 insertion(+), 2 deletions(-)

>

> diff --git a/arch/um/Makefile b/arch/um/Makefile

> index e54dda8..de340e4 100644

> --- a/arch/um/Makefile

> +++ b/arch/um/Makefile

> @@ -122,8 +122,7 @@ archheaders:

>         $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.asm-generic \

>                     kbuild-file=$(HOST_DIR)/include/uapi/asm/Kbuild \

>                     obj=$(HOST_DIR)/include/generated/uapi/asm

> -       $(Q)$(MAKE) KBUILD_SRC= ARCH=$(HEADER_ARCH) archheaders

> -

> +       $(Q)$(MAKE) -f $(srctree)/Makefile ARCH=$(HEADER_ARCH) archheaders

>

>  archprepare: include/generated/user_constants.h

>

> --

> 2.7.4

>

> --

> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in

> the body of a message to majordomo@vger.kernel.org

> More majordomo info at  http://vger.kernel.org/majordomo-info.html




-- 
Best Regards
Masahiro Yamada

On Fri, Aug 3, 2018 at 9:47 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Randy Dunlap reports UML occasionally fails to build with -j<N> and

> O=<builddir> options.


With v4.19-rc2 I'm still seeing a failure (for any parallelism) under ARCH=um

$ make -j8 ARCH=um O=/tmp/foo
...
/home/kees/src/linux-build/um/Makefile:1185: *** Headers not
exportable for the um architecture.  Stop.

Am I missing something?

-Kees

-- 
Kees Cook
Pixel Security

Hi Kees,


2018-09-16 3:47 GMT+09:00 Kees Cook <keescook@chromium.org>:
> On Fri, Aug 3, 2018 at 9:47 PM, Masahiro Yamada

> <yamada.masahiro@socionext.com> wrote:

>> Randy Dunlap reports UML occasionally fails to build with -j<N> and

>> O=<builddir> options.

>

> With v4.19-rc2 I'm still seeing a failure (for any parallelism) under ARCH=um

>

> $ make -j8 ARCH=um O=/tmp/foo

> ...

> /home/kees/src/linux-build/um/Makefile:1185: *** Headers not

> exportable for the um architecture.  Stop.

>

> Am I missing something?



This is a different problem.

I sent a patch:
https://patchwork.kernel.org/patch/10603707/



-- 
Best Regards
Masahiro Yamada