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]
Message-ID: <CADYN=9L2-yaOvxp8j23O9Sp15mgFZrPUsEZBOWi=UngYyXNJpQ@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ