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

[Jon Hunter <jonathanh@nvidia.com>]

On 11/12/2024 02:39, Masahiro Yamada wrote:
> On Wed, Dec 11, 2024 at 12:34 AM Jon Hunter <jonathanh@nvidia.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@kernel.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.


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?

Jon

-- 
nvpublic