On Wed, Dec 11, 2024 at 9:21 PM Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
>
>
> On 11/12/2024 02:39, Masahiro Yamada wrote:
> > On Wed, Dec 11, 2024 at 12:34 AM Jon Hunter <jonathanh@xxxxxxxxxx> 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@xxxxxxxxxx>
> >>
> >>
> >> 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.
>
>
> So this is not explicitly checking the path, but comparing the contents
> of the Module.symvers before and after this change for the external
> module I see ...
>
> $ grep -r host1x_device_init Module.symvers
> 0x00000000 host1x_device_init /absolute/path/to/drivers/gpu/host1x/host1x EXPORT_SYMBOL
>
> And now I see ...
>
> $ grep -r host1x_device_init Module.symvers
> 0x00000000 host1x_device_init drivers/gpu/host1x/host1x EXPORT_SYMBOL
>
> So the problem is that now there is no longer an absolute path in the
> external modules Module.symvers and so conflicts with the kernel's.
>
> Does that make sense?
As I said, I do not know how to reproduce it.
Please provide the steps to reproduce it.
--
Best Regards
Masahiro Yamada
