| Message ID | 20180131201911.19253-1-anders.roxell@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [PATCHv2] arch/arm/Kconfig: default ARM_MODULE_PLTS to 'y' | expand |
On 31 January 2018 at 20:19, Anders Roxell <anders.roxell@linaro.org> wrote: > While testing multi_v7_defconfig with LOCKDEP enabled, the kernel > fails to load simple modules, as reported by kselftest: > > [ 34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation > 28 out of range (0xbf046044 -> 0xc109f720) > selftests: printf.sh [FAIL] > > The problem that is seen when LOCKDEP is enabled without > ARM_MODULE_PLTS, is that LOCKDEP eats so much memory that the top of the > kernel gets out of reach from the bottom of the module area. > > Suggested-by: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > --- > arch/arm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 51c8df561077..8014c8c322df 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1702,6 +1702,7 @@ config ARCH_WANT_GENERAL_HUGETLB > config ARM_MODULE_PLTS > bool "Use PLTs to allow module memory to spill over into vmalloc area" > depends on MODULES > + default y > help > Allocate PLTs when loading modules so that jumps and calls whose > targets are too far away for their relative offsets to be encoded > -- > 2.11.0 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jan 31, 2018 at 9:19 PM, Anders Roxell <anders.roxell@linaro.org> wrote: > While testing multi_v7_defconfig with LOCKDEP enabled, the kernel > fails to load simple modules, as reported by kselftest: > > [ 34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation > 28 out of range (0xbf046044 -> 0xc109f720) > selftests: printf.sh [FAIL] > > The problem that is seen when LOCKDEP is enabled without > ARM_MODULE_PLTS, is that LOCKDEP eats so much memory that the top of the > kernel gets out of reach from the bottom of the module area. I think we could still use a better explanation here, as Russell said anything could cause the size to grow too much, it's just that you happened to run into it through lockdep, which can cause a very significant growth. Arnd > Suggested-by: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Anders Roxell <anders.roxell@linaro.org> > --- > arch/arm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 51c8df561077..8014c8c322df 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1702,6 +1702,7 @@ config ARCH_WANT_GENERAL_HUGETLB > config ARM_MODULE_PLTS > bool "Use PLTs to allow module memory to spill over into vmalloc area" > depends on MODULES > + default y > help > Allocate PLTs when loading modules so that jumps and calls whose > targets are too far away for their relative offsets to be encoded > -- > 2.11.0 >
On Wed, Jan 31, 2018 at 09:19:11PM +0100, Anders Roxell wrote: > While testing multi_v7_defconfig with LOCKDEP enabled, the kernel > fails to load simple modules, as reported by kselftest: > > [ 34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation > 28 out of range (0xbf046044 -> 0xc109f720) > selftests: printf.sh [FAIL] > > The problem that is seen when LOCKDEP is enabled without > ARM_MODULE_PLTS, is that LOCKDEP eats so much memory that the top of the > kernel gets out of reach from the bottom of the module area. As I've said three times already (and clearly the message still hasn't sunk in), it does _not_ follow that "enable lockdep" means "lots more memory used". We could say the same thing about several other kernel options as well. Please remove this from your commit message. <exasperation at seemingly being ignored on this point> Maybe you'd like to send your configuration file so we can see how much is enabled in your kernel. At that point I'll make a decision, but until then, I'm not going to say that even what I suggested is an acceptable way forward. > > Suggested-by: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Anders Roxell <anders.roxell@linaro.org> > --- > arch/arm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 51c8df561077..8014c8c322df 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1702,6 +1702,7 @@ config ARCH_WANT_GENERAL_HUGETLB > config ARM_MODULE_PLTS > bool "Use PLTs to allow module memory to spill over into vmalloc area" > depends on MODULES > + default y > help > Allocate PLTs when loading modules so that jumps and calls whose > targets are too far away for their relative offsets to be encoded > -- > 2.11.0 > -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
On 31 January 2018 at 21:25, Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > On Wed, Jan 31, 2018 at 09:19:11PM +0100, Anders Roxell wrote: >> While testing multi_v7_defconfig with LOCKDEP enabled, the kernel >> fails to load simple modules, as reported by kselftest: >> >> [ 34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation >> 28 out of range (0xbf046044 -> 0xc109f720) >> selftests: printf.sh [FAIL] >> >> The problem that is seen when LOCKDEP is enabled without >> ARM_MODULE_PLTS, is that LOCKDEP eats so much memory that the top of the >> kernel gets out of reach from the bottom of the module area. > > As I've said three times already (and clearly the message still hasn't > sunk in), it does _not_ follow that "enable lockdep" means "lots more > memory used". We could say the same thing about several other kernel > options as well. Please remove this from your commit message. Sorry, I meant to show this as an example in v2, but forgot to update this part of the change log. > > <exasperation at seemingly being ignored on this point> > > Maybe you'd like to send your configuration file so we can see how much > is enabled in your kernel. At that point I'll make a decision, but > until then, I'm not going to say that even what I suggested is an > acceptable way forward. Here's the config file[1] that is using. I'm obviously ignorant here, but whats the disadvantages of enabling this option by default? My understanding is that the module size gets slightly larger by enabling this option but nothing else? Obviously, if the default is changed to yes, the last part of this option's help message also need to change. To something like: "Say n if you know that you wont get out of memory errors while loading modules" Cheers, Anders [1] http://snapshots.linaro.org/openembedded/lkft/morty/am57xx-evm/rpb/linux-mainline/622/config > >> >> Suggested-by: Arnd Bergmann <arnd@arndb.de> >> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> >> --- >> arch/arm/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 51c8df561077..8014c8c322df 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -1702,6 +1702,7 @@ config ARCH_WANT_GENERAL_HUGETLB >> config ARM_MODULE_PLTS >> bool "Use PLTs to allow module memory to spill over into vmalloc area" >> depends on MODULES >> + default y >> help >> Allocate PLTs when loading modules so that jumps and calls whose >> targets are too far away for their relative offsets to be encoded >> -- >> 2.11.0 >> > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up > According to speedtest.net: 8.21Mbps down 510kbps up
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 51c8df561077..8014c8c322df 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1702,6 +1702,7 @@ config ARCH_WANT_GENERAL_HUGETLB config ARM_MODULE_PLTS bool "Use PLTs to allow module memory to spill over into vmalloc area" depends on MODULES + default y help Allocate PLTs when loading modules so that jumps and calls whose targets are too far away for their relative offsets to be encoded
While testing multi_v7_defconfig with LOCKDEP enabled, the kernel fails to load simple modules, as reported by kselftest: [ 34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation 28 out of range (0xbf046044 -> 0xc109f720) selftests: printf.sh [FAIL] The problem that is seen when LOCKDEP is enabled without ARM_MODULE_PLTS, is that LOCKDEP eats so much memory that the top of the kernel gets out of reach from the bottom of the module area. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) -- 2.11.0