* Re: [PATCH v2 05/11] kbuild: change working directory to external module directory with M= [not found] ` <20241110013649.34903-6-masahiroy@kernel.org> @ 2024-12-10 15:34 ` Jon Hunter 2024-12-11 2:39 ` Masahiro Yamada 0 siblings, 1 reply; 6+ messages in thread From: Jon Hunter @ 2024-12-10 15:34 UTC (permalink / raw) To: Masahiro Yamada, linux-kbuild Cc: linux-kernel, rust-for-linux, cocci, linux-tegra@vger.kernel.org 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. Thanks Jon -- nvpublic ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 05/11] kbuild: change working directory to external module directory with M= 2024-12-10 15:34 ` [PATCH v2 05/11] kbuild: change working directory to external module directory with M= Jon Hunter @ 2024-12-11 2:39 ` Masahiro Yamada 2024-12-11 12:21 ` Jon Hunter 0 siblings, 1 reply; 6+ messages in thread From: Masahiro Yamada @ 2024-12-11 2:39 UTC (permalink / raw) To: Jon Hunter Cc: linux-kbuild, linux-kernel, rust-for-linux, cocci, linux-tegra@vger.kernel.org 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. -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 05/11] kbuild: change working directory to external module directory with M= 2024-12-11 2:39 ` Masahiro Yamada @ 2024-12-11 12:21 ` Jon Hunter 2024-12-12 2:08 ` Masahiro Yamada 0 siblings, 1 reply; 6+ messages in thread From: Jon Hunter @ 2024-12-11 12:21 UTC (permalink / raw) To: Masahiro Yamada Cc: linux-kbuild, linux-kernel, rust-for-linux, cocci, linux-tegra@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 05/11] kbuild: change working directory to external module directory with M= 2024-12-11 12:21 ` Jon Hunter @ 2024-12-12 2:08 ` Masahiro Yamada 2024-12-12 6:00 ` Jon Hunter 0 siblings, 1 reply; 6+ messages in thread From: Masahiro Yamada @ 2024-12-12 2:08 UTC (permalink / raw) To: Jon Hunter Cc: linux-kbuild, linux-kernel, rust-for-linux, cocci, linux-tegra@vger.kernel.org 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. -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 05/11] kbuild: change working directory to external module directory with M= 2024-12-12 2:08 ` Masahiro Yamada @ 2024-12-12 6:00 ` Jon Hunter 2024-12-12 15:49 ` Masahiro Yamada 0 siblings, 1 reply; 6+ messages in thread From: Jon Hunter @ 2024-12-12 6:00 UTC (permalink / raw) To: Masahiro Yamada Cc: linux-kbuild, linux-kernel, rust-for-linux, cocci, linux-tegra@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 05/11] kbuild: change working directory to external module directory with M= 2024-12-12 6:00 ` Jon Hunter @ 2024-12-12 15:49 ` Masahiro Yamada 0 siblings, 0 replies; 6+ messages in thread From: Masahiro Yamada @ 2024-12-12 15:49 UTC (permalink / raw) To: Jon Hunter Cc: linux-kbuild, linux-kernel, rust-for-linux, cocci, linux-tegra@vger.kernel.org On Thu, Dec 12, 2024 at 3:00 PM Jon Hunter <jonathanh@nvidia.com> wrote: > > > 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 OK, now I understand, and posted a patch. Thanks. -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-12-12 15:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20241110013649.34903-1-masahiroy@kernel.org>
[not found] ` <20241110013649.34903-6-masahiroy@kernel.org>
2024-12-10 15:34 ` [PATCH v2 05/11] kbuild: change working directory to external module directory with M= Jon Hunter
2024-12-11 2:39 ` Masahiro Yamada
2024-12-11 12:21 ` Jon Hunter
2024-12-12 2:08 ` Masahiro Yamada
2024-12-12 6:00 ` Jon Hunter
2024-12-12 15:49 ` Masahiro Yamada
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox