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

[Jon Hunter <jonathanh@nvidia.com>]

On 12/12/2024 02:08, Masahiro Yamada wrote:
> On Wed, Dec 11, 2024 at 9:21 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>>
>> 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?
> 
> 
> As I said, I do not know how to reproduce it.
> 
> Please provide the steps to reproduce it.

Got it! The steps would be ...

1. Create an external module by copying using an existing upstream
    driver (such as host1x).
2. Create a new external module that uses the external module from step
    1 and uses KBUILD_EXTRA_SYMBOLS to reference the Module.symvers for
    the driver in step 1.

Thanks!
Jon

-- 
nvpublic