lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 25 Oct 2017 21:21:48 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Richard Weinberger <richard.weinberger@...il.com>,
        linux-kbuild <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Sam Ravnborg <sam@...nborg.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Michal Marek <michal.lkml@...kovi.net>
Subject: Re: [PATCH v2 3/5] kbuild: Use relative path for $(objtree)

Hi Geert,

(+CC Michal's new address)


2017-10-16 19:26 GMT+09:00 Geert Uytterhoeven <geert@...ux-m68k.org>:
> Hi Michal,
>
> On Thu, Jun 5, 2014 at 5:56 PM, Michal Marek <mmarek@...e.cz> wrote:
>> On Wed, Jun 04, 2014 at 03:12:33PM +0200, Michal Marek wrote:
>>> On 2014-06-04 11:43, Michal Marek wrote:
>>> > On 2014-06-04 11:03, Richard Weinberger wrote:
>>> >> To reproduce run:
>>> >> make defconfig ARCH=um O=/mnt/o && make linux ARCH=um O=/mnt/
>>> >>
>>> >> If there is anything in UML which needs fixing, please tell. :-)
>>> >
>>> > I'll have a look, thanks for the report.
>>>
>>> Findings so far: For some reason, syscalls_32.h is generated in the
>>> source tree (which is wrong) and syscalls_64.h is not generated at all.
>>> Looking further.
>>
>> Can you try the below patch? The same pattern is used in the rules for
>> tools/ and tools/% in the main Makefile, need to look into that as well.
>> But UML should work now.
>>
>> Michal
>>
>> From d4bc590f8716f7dde6b7bca319097ac30a8cb0b4 Mon Sep 17 00:00:00 2001
>> From: Michal Marek <mmarek@...e.cz>
>> Date: Thu, 5 Jun 2014 17:44:44 +0200
>> Subject: [PATCH] um: Fix for relative objtree when generating x86 headers
>>
>> In an O= build, rely on the generated Makefile to call the main Makefile
>> properly. When building in the source tree, we do not need to specify
>> the -C and O= either. This fixes the problem when $(objtree) is a
>> relative path and the -C changes the directory.
>>
>> Reported-by: Richard Weinberger <richard.weinberger@...il.com>
>> Signed-off-by: Michal Marek <mmarek@...e.cz>
>> ---
>>  arch/um/Makefile | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/um/Makefile b/arch/um/Makefile
>> index 36e658a..e4b1a96 100644
>> --- a/arch/um/Makefile
>> +++ b/arch/um/Makefile
>> @@ -111,8 +111,7 @@ endef
>>  KBUILD_KCONFIG := $(HOST_DIR)/um/Kconfig
>>
>>  archheaders:
>> -       $(Q)$(MAKE) -C '$(srctree)' KBUILD_SRC= \
>> -               ARCH=$(HEADER_ARCH) O='$(objtree)' archheaders
>> +       $(Q)$(MAKE) KBUILD_SRC= ARCH=$(HEADER_ARCH) archheaders
>>
>>  archprepare: include/generated/user_constants.h
>
> This now commit d4bc590f8716f7dd ("um: Fix for relative objtree when
> generating x86 headers").
>
> When using O=, the build enters an infinite loop on v4.14-rc5.


Strange. I can not reproduce this.

For example, the following command works fine for me.

make ARCH=um  O=foo/bar  defconfig all


Could you share the command you input?



> With V=1:
>
>     make KBUILD_SRC= ARCH=x86 archheaders
>     make -C /scratch/geert/linux/linux
> O=/scratch/geert/build/linux-uml-amd64/. archheaders
>     make -C /scratch/geert/build/linux-uml-amd64
> KBUILD_SRC=/scratch/geert/linux/linux \
>     -f /scratch/geert/linux/linux/Makefile archheaders
>     make KBUILD_SRC= ARCH=x86 archheaders
>     make -C /scratch/geert/linux/linux
> O=/scratch/geert/build/linux-uml-amd64/. archheaders
>     make -C /scratch/geert/build/linux-uml-amd64
> KBUILD_SRC=/scratch/geert/linux/linux \
>     -f /scratch/geert/linux/linux/Makefile archheaders
>     ...
>
> As it's been a (long) while I buily UML, I started a bisect, which pointed to
> the commit above.
> The problem actually already happened on commit d4bc590f8716f7dd, so this
> has been broken since v3.16:
>
>     make KBUILD_SRC= ARCH=x86 archheaders
>     make -C /scratch/geert/linux/linux
> O=/scratch/geert/build/linux-uml-amd64/. archheaders
>     make -C /scratch/geert/build/linux-uml-amd64 \
>     KBUILD_SRC=/scratch/geert/linux/linux \
>     KBUILD_EXTMOD="" -f /scratch/geert/linux/linux/Makefile \
>     archheaders
>     make KBUILD_SRC= ARCH=x86 archheaders
>     make -C /scratch/geert/linux/linux
> O=/scratch/geert/build/linux-uml-amd64/. archheaders
>     make -C /scratch/geert/build/linux-uml-amd64 \
>     KBUILD_SRC=/scratch/geert/linux/linux \
>     KBUILD_EXTMOD="" -f /scratch/geert/linux/linux/Makefile \
>     archheaders
>     ...
>
> Unfortunately reverting that commit doesn't help, as that causes the
> failure that
> commit was supposed to fix:
>
>     /scratch/geert/linux/linux/arch/x86/um/user-offsets.c:19:29: fatal
> error: asm/syscalls_64.h: No such file or directory
>      #include <asm/syscalls_64.h>
>                                  ^
>     compilation terminated.
>     /scratch/geert/linux/linux/scripts/Makefile.build:154: recipe for
> target 'arch/x86/um/user-offsets.s' failed
>
> Do you have any clue? Thanks!
>
> Gr{oetje,eeting}s,



-- 
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists