Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] arm64: Allow user selection of ARM64_MODULE_PLTS
@ 2019-06-14  2:59 Florian Fainelli
  2019-06-14  7:02 ` Ard Biesheuvel
  2019-06-17 17:32 ` Will Deacon
  0 siblings, 2 replies; 5+ messages in thread
From: Florian Fainelli @ 2019-06-14  2:59 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Florian Fainelli, ard.biesheuvel, Catalin Marinas, Will Deacon,
	open list, bcm-kernel-feedback-list,
	moderated list:ARM64 PORT AARCH64 ARCHITECTURE

Make ARM64_MODULE_PLTS a selectable Kconfig symbol, since some people
might have very big modules spilling out of the dedicated module area
into vmalloc. Help text is copied from the ARM 32-bit counterpart.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm64/Kconfig | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 697ea0510729..36befe987b73 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1418,8 +1418,20 @@ config ARM64_SVE
 	  KVM in the same kernel image.
 
 config ARM64_MODULE_PLTS
-	bool
+	bool "Use PLTs to allow module memory to spill over into vmalloc area"
 	select HAVE_MOD_ARCH_SPECIFIC
+	help
+	  Allocate PLTs when loading modules so that jumps and calls whose
+	  targets are too far away for their relative offsets to be encoded
+	  in the instructions themselves can be bounced via veneers in the
+	  module's PLT. This allows modules to be allocated in the generic
+	  vmalloc area after the dedicated module memory area has been
+	  exhausted. The modules will use slightly more memory, but after
+	  rounding up to page size, the actual memory footprint is usually
+	  the same.
+
+	  Disabling this is usually safe for small single-platform
+	  configurations. If unsure, say y.
 
 config ARM64_PSEUDO_NMI
 	bool "Support for NMI-like interrupts"
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] arm64: Allow user selection of ARM64_MODULE_PLTS
  2019-06-14  2:59 [PATCH] arm64: Allow user selection of ARM64_MODULE_PLTS Florian Fainelli
@ 2019-06-14  7:02 ` Ard Biesheuvel
  2019-06-17 17:32 ` Will Deacon
  1 sibling, 0 replies; 5+ messages in thread
From: Ard Biesheuvel @ 2019-06-14  7:02 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Catalin Marinas, Will Deacon, open list,
	bcm-kernel-feedback-list, linux-arm-kernel,
	moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)

On Fri, 14 Jun 2019 at 04:59, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> Make ARM64_MODULE_PLTS a selectable Kconfig symbol, since some people
> might have very big modules spilling out of the dedicated module area
> into vmalloc. Help text is copied from the ARM 32-bit counterpart.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
>  arch/arm64/Kconfig | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 697ea0510729..36befe987b73 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1418,8 +1418,20 @@ config ARM64_SVE
>           KVM in the same kernel image.
>
>  config ARM64_MODULE_PLTS
> -       bool
> +       bool "Use PLTs to allow module memory to spill over into vmalloc area"
>         select HAVE_MOD_ARCH_SPECIFIC
> +       help
> +         Allocate PLTs when loading modules so that jumps and calls whose
> +         targets are too far away for their relative offsets to be encoded
> +         in the instructions themselves can be bounced via veneers in the
> +         module's PLT. This allows modules to be allocated in the generic
> +         vmalloc area after the dedicated module memory area has been
> +         exhausted. The modules will use slightly more memory, but after
> +         rounding up to page size, the actual memory footprint is usually
> +         the same.
> +
> +         Disabling this is usually safe for small single-platform
> +         configurations. If unsure, say y.
>

I don't mind adding this, but it makes sense to add an explanation why
KASLR enables this. E.g.,

"""
When running with address space randomization (KASLR), the module
region itself may be too far away for ordinary relative jumps and
calls, and so in that case, module PLTs are required and cannot be
disabled.
"""

>  config ARM64_PSEUDO_NMI
>         bool "Support for NMI-like interrupts"
> --
> 2.17.1
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] arm64: Allow user selection of ARM64_MODULE_PLTS
  2019-06-14  2:59 [PATCH] arm64: Allow user selection of ARM64_MODULE_PLTS Florian Fainelli
  2019-06-14  7:02 ` Ard Biesheuvel
@ 2019-06-17 17:32 ` Will Deacon
  2019-06-17 18:03   ` Florian Fainelli
  1 sibling, 1 reply; 5+ messages in thread
From: Will Deacon @ 2019-06-17 17:32 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: ard.biesheuvel, Catalin Marinas, open list,
	bcm-kernel-feedback-list, linux-arm-kernel,
	moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)

On Thu, Jun 13, 2019 at 07:59:32PM -0700, Florian Fainelli wrote:
> Make ARM64_MODULE_PLTS a selectable Kconfig symbol, since some people
> might have very big modules spilling out of the dedicated module area
> into vmalloc. Help text is copied from the ARM 32-bit counterpart.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
>  arch/arm64/Kconfig | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 697ea0510729..36befe987b73 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1418,8 +1418,20 @@ config ARM64_SVE
>  	  KVM in the same kernel image.
>  
>  config ARM64_MODULE_PLTS
> -	bool
> +	bool "Use PLTs to allow module memory to spill over into vmalloc area"
>  	select HAVE_MOD_ARCH_SPECIFIC
> +	help
> +	  Allocate PLTs when loading modules so that jumps and calls whose
> +	  targets are too far away for their relative offsets to be encoded
> +	  in the instructions themselves can be bounced via veneers in the
> +	  module's PLT. This allows modules to be allocated in the generic
> +	  vmalloc area after the dedicated module memory area has been
> +	  exhausted. The modules will use slightly more memory, but after
> +	  rounding up to page size, the actual memory footprint is usually
> +	  the same.

Isn't the worry really about the runtime performance overhead introduced
by the veneers, as opposed to the memory usage of the module?

> +	  Disabling this is usually safe for small single-platform
> +	  configurations. If unsure, say y.

So should this be on by default?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] arm64: Allow user selection of ARM64_MODULE_PLTS
  2019-06-17 17:32 ` Will Deacon
@ 2019-06-17 18:03   ` Florian Fainelli
  2019-06-17 18:10     ` Will Deacon
  0 siblings, 1 reply; 5+ messages in thread
From: Florian Fainelli @ 2019-06-17 18:03 UTC (permalink / raw)
  To: Will Deacon
  Cc: ard.biesheuvel, Catalin Marinas, open list,
	bcm-kernel-feedback-list, linux-arm-kernel,
	moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)

On 6/17/19 10:32 AM, Will Deacon wrote:
> On Thu, Jun 13, 2019 at 07:59:32PM -0700, Florian Fainelli wrote:
>> Make ARM64_MODULE_PLTS a selectable Kconfig symbol, since some people
>> might have very big modules spilling out of the dedicated module area
>> into vmalloc. Help text is copied from the ARM 32-bit counterpart.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>>  arch/arm64/Kconfig | 14 +++++++++++++-
>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 697ea0510729..36befe987b73 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -1418,8 +1418,20 @@ config ARM64_SVE
>>  	  KVM in the same kernel image.
>>  
>>  config ARM64_MODULE_PLTS
>> -	bool
>> +	bool "Use PLTs to allow module memory to spill over into vmalloc area"
>>  	select HAVE_MOD_ARCH_SPECIFIC
>> +	help
>> +	  Allocate PLTs when loading modules so that jumps and calls whose
>> +	  targets are too far away for their relative offsets to be encoded
>> +	  in the instructions themselves can be bounced via veneers in the
>> +	  module's PLT. This allows modules to be allocated in the generic
>> +	  vmalloc area after the dedicated module memory area has been
>> +	  exhausted. The modules will use slightly more memory, but after
>> +	  rounding up to page size, the actual memory footprint is usually
>> +	  the same.
> 
> Isn't the worry really about the runtime performance overhead introduced
> by the veneers, as opposed to the memory usage of the module?

The main concern is indeed runtime performance (both added veneers and
possibly increased cache trashing) and second could be the increased
vmalloc usage. Do you want me to rephrase that part, or drop it?

> 
>> +	  Disabling this is usually safe for small single-platform
>> +	  configurations. If unsure, say y.
> 
> So should this be on by default?

It is turned on under certain conditions that require it (v2 makes that
clearer, based on Ard's feedback), having it turned off by default at
least makes people realize (or rather can be used as argument) that the
modules are possibly too big.

Under certain build configurations like test/manufacturing, you might
have a set of large modules that should still load, hence this patch.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] arm64: Allow user selection of ARM64_MODULE_PLTS
  2019-06-17 18:03   ` Florian Fainelli
@ 2019-06-17 18:10     ` Will Deacon
  0 siblings, 0 replies; 5+ messages in thread
From: Will Deacon @ 2019-06-17 18:10 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: ard.biesheuvel, Catalin Marinas, Will Deacon, open list,
	bcm-kernel-feedback-list, linux-arm-kernel,
	moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)

On Mon, Jun 17, 2019 at 11:03:28AM -0700, Florian Fainelli wrote:
> On 6/17/19 10:32 AM, Will Deacon wrote:
> > On Thu, Jun 13, 2019 at 07:59:32PM -0700, Florian Fainelli wrote:
> >> Make ARM64_MODULE_PLTS a selectable Kconfig symbol, since some people
> >> might have very big modules spilling out of the dedicated module area
> >> into vmalloc. Help text is copied from the ARM 32-bit counterpart.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >>  arch/arm64/Kconfig | 14 +++++++++++++-
> >>  1 file changed, 13 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >> index 697ea0510729..36befe987b73 100644
> >> --- a/arch/arm64/Kconfig
> >> +++ b/arch/arm64/Kconfig
> >> @@ -1418,8 +1418,20 @@ config ARM64_SVE
> >>  	  KVM in the same kernel image.
> >>  
> >>  config ARM64_MODULE_PLTS
> >> -	bool
> >> +	bool "Use PLTs to allow module memory to spill over into vmalloc area"
> >>  	select HAVE_MOD_ARCH_SPECIFIC
> >> +	help
> >> +	  Allocate PLTs when loading modules so that jumps and calls whose
> >> +	  targets are too far away for their relative offsets to be encoded
> >> +	  in the instructions themselves can be bounced via veneers in the
> >> +	  module's PLT. This allows modules to be allocated in the generic
> >> +	  vmalloc area after the dedicated module memory area has been
> >> +	  exhausted. The modules will use slightly more memory, but after
> >> +	  rounding up to page size, the actual memory footprint is usually
> >> +	  the same.
> > 
> > Isn't the worry really about the runtime performance overhead introduced
> > by the veneers, as opposed to the memory usage of the module?
> 
> The main concern is indeed runtime performance (both added veneers and
> possibly increased cache trashing) and second could be the increased
> vmalloc usage. Do you want me to rephrase that part, or drop it?

Whichever you prefer.

> > 
> >> +	  Disabling this is usually safe for small single-platform
> >> +	  configurations. If unsure, say y.
> > 
> > So should this be on by default?
> 
> It is turned on under certain conditions that require it (v2 makes that
> clearer, based on Ard's feedback), having it turned off by default at
> least makes people realize (or rather can be used as argument) that the
> modules are possibly too big.
> 
> Under certain build configurations like test/manufacturing, you might
> have a set of large modules that should still load, hence this patch.

I'm fine with leaving it default off, but then let's not say "If unsure, say
y". In fact, you can remove that whole "disabling this is usually safe" part
I reckon.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-14  2:59 [PATCH] arm64: Allow user selection of ARM64_MODULE_PLTS Florian Fainelli
2019-06-14  7:02 ` Ard Biesheuvel
2019-06-17 17:32 ` Will Deacon
2019-06-17 18:03   ` Florian Fainelli
2019-06-17 18:10     ` Will Deacon

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org infradead-linux-arm-kernel@archiver.kernel.org
	public-inbox-index linux-arm-kernel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox