linux-kernel - Re: [PATCH v2 05/11] kbuild: change working directory to external module directory with M=

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bdd5ff13-ec66-4ab6-985a-1fe433e85f91@nvidia.com>
Date: Tue, 10 Dec 2024 15:34:37 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Masahiro Yamada <masahiroy@...nel.org>, linux-kbuild@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
 cocci@...ia.fr, "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v2 05/11] kbuild: change working directory to external
 module directory with M=

Hi Masahiro,

On 10/11/2024 01:34, Masahiro Yamada wrote:
> Currently, Kbuild always operates in the output directory of the kernel,
> even when building external modules. This increases the risk of external
> module Makefiles attempting to write to the kernel directory.
> 
> This commit switches the working directory to the external module
> directory, allowing the removal of the $(KBUILD_EXTMOD)/ prefix from
> some build artifacts.
> 
> The command for building external modules maintains backward
> compatibility, but Makefiles that rely on working in the kernel
> directory may break. In such cases, $(objtree) and $(srctree) should
> be used to refer to the output and source directories of the kernel.
> 
> The appearance of the build log will change as follows:
> 
> [Before]
> 
>    $ make -C /path/to/my/linux M=/path/to/my/externel/module
>    make: Entering directory '/path/to/my/linux'
>      CC [M]  /path/to/my/externel/module/helloworld.o
>      MODPOST /path/to/my/externel/module/Module.symvers
>      CC [M]  /path/to/my/externel/module/helloworld.mod.o
>      CC [M]  /path/to/my/externel/module/.module-common.o
>      LD [M]  /path/to/my/externel/module/helloworld.ko
>    make: Leaving directory '/path/to/my/linux'
> 
> [After]
> 
>    $ make -C /path/to/my/linux M=/path/to/my/externel/module
>    make: Entering directory '/path/to/my/linux'
>    make[1]: Entering directory '/path/to/my/externel/module'
>      CC [M]  helloworld.o
>      MODPOST Module.symvers
>      CC [M]  helloworld.mod.o
>      CC [M]  .module-common.o
>      LD [M]  helloworld.ko
>    make[1]: Leaving directory '/path/to/my/externel/module'
>    make: Leaving directory '/path/to/my/linux'
> 
> Printing "Entering directory" twice is cumbersome. This will be
> addressed later.
> 
> Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>


Since this change I have been observing the following build error when 
building an external module ...

  MODPOST Module.symvers
ERROR: modpost: drivers/gpu/host1x/host1x: 'host1x_device_init' exported
     twice. Previous export was in drivers/gpu/host1x/host1x.ko
ERROR: modpost: drivers/gpu/host1x/host1x: 'host1x_device_exit' exported
     twice. Previous export was in drivers/gpu/host1x/host1x.ko

Now host1x is an upstream driver, but I have a local copy that using to 
stage development changes (and avoid polluting the upstream driver). 
Plus I can swap between which version I am using on a live system.

What I noticed is that previously the Modules.symvers for the external 
module had the full path of the external module for the name. However, 
now the name is just the relative path and in this case 
'drivers/gpu/host1x/host1x'. Hence, this clashes with the in-kernel 
driver and we get the 'exported twice' error.

I have been looking to see if there is a way to fix this because it has 
been a useful feature to override an upstream driver with a locally 
modified version.

Thanks
Jon

-- 
nvpublic