linux-kernel - Re: [PATCHv2] arch/arm/Kconfig: default ARM_MODULE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 14 Feb 2018 21:46:35 +0100
From:   Anders Roxell <anders.roxell@...aro.org>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCHv2] arch/arm/Kconfig: default ARM_MODULE_PLTS to 'y'

On 31 January 2018 at 21:25, Russell King - ARM Linux
<linux@...linux.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@...db.de>
>> Signed-off-by: Anders Roxell <anders.roxell@...aro.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