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: <CAK7LNATgL=vOr37+XfF7du+_ak5yKgXYyNNNTEQdVvy5J2MMyA@mail.gmail.com>
Date: Wed, 11 Dec 2024 11:39:27 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Jon Hunter <jonathanh@...dia.com>
Cc: linux-kbuild@...r.kernel.org, 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=

On Wed, Dec 11, 2024 at 12:34 AM Jon Hunter <jonathanh@...dia.com> wrote:
>
> 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.


I do not know how to reproduce it.

  if (s && (!external_module || s->module->is_vmlinux || s->module == mod)) {

is not checking the module path at all.
I do not understand why it was affected.



-- 
Best Regards
Masahiro Yamada