[PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation

[PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation

[Florian Fainelli]

With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
done from module space will fail, produce a general OOM allocation and also a
vmap warning. The second allocation from vmalloc space may or may not be
successful, but is actually the one we are interested about in these cases.

This patch series passed __GFP_NOWARN to silence such allocations from the
ARM/ARM64 module loader's first time allocation when the MODULES_PLT option is
enabled, and also makes alloc_vmap_area() react to the caller setting
__GFP_NOWARN to silence "vmap allocation for size..." messages.


Changes in v3:
- check for __GFP_NOWARN not set where the check for printk_ratelimited()
  is done, add Michal's Acked-by

- use C conditionals and not CPP conditionals for IS_ENABLED(), add Ard's
  Reviewed-by tag

Changes in v2:

- check __GFP_NOWARN out of the printk_ratelimited() check (Michal)

Here is an example of what we would get without these two patches, pretty
scary huh?

# insmod /mnt/nfs/huge.ko 
[   22.114143] random: nonblocking pool is initialized
[   22.183575] vmap allocation for size 15736832 failed: use vmalloc=<size> to increase size.
[   22.191873] vmalloc: allocation failure: 15729534 bytes
[   22.197112] insmod: page allocation failure: order:0, mode:0xd0
[   22.203048] CPU: 2 PID: 1506 Comm: insmod Tainted: G           O    4.1.20-1.9pre-01082-gbbbff07bc3ce #9
[   22.212536] Hardware name: Broadcom STB (Flattened Device Tree)
[   22.218480] [<c0017eec>] (unwind_backtrace) from [<c00135c8>] (show_stack+0x10/0x14)
[   22.226238] [<c00135c8>] (show_stack) from [<c0638684>] (dump_stack+0x90/0xa4)
[   22.233473] [<c0638684>] (dump_stack) from [<c00aae1c>] (warn_alloc_failed+0x104/0x144)
[   22.241490] [<c00aae1c>] (warn_alloc_failed) from [<c00d72e0>] (__vmalloc_node_range+0x170/0x218)
[   22.250375] [<c00d72e0>] (__vmalloc_node_range) from [<c00147d0>] (module_alloc+0x50/0xac)
[   22.258651] [<c00147d0>] (module_alloc) from [<c008ae2c>] (module_alloc_update_bounds+0xc/0x6c)
[   22.267360] [<c008ae2c>] (module_alloc_update_bounds) from [<c008b778>] (load_module+0x8ec/0x2058)
[   22.276329] [<c008b778>] (load_module) from [<c008cfd4>] (SyS_init_module+0xf0/0x174)
[   22.284170] [<c008cfd4>] (SyS_init_module) from [<c0010140>] (ret_fast_syscall+0x0/0x3c)
[   22.292277] Mem-Info:
[   22.294567] active_anon:5236 inactive_anon:1773 isolated_anon:0
[   22.294567]  active_file:1 inactive_file:3822 isolated_file:0
[   22.294567]  unevictable:0 dirty:0 writeback:0 unstable:0
[   22.294567]  slab_reclaimable:238 slab_unreclaimable:1594
[   22.294567]  mapped:855 shmem:2950 pagetables:36 bounce:0
[   22.294567]  free:39031 free_pcp:198 free_cma:3928
[   22.327196] DMA free:156124kB min:1880kB low:2348kB high:2820kB active_anon:20944kB inactive_anon:7092kB active_file:4kB inactive_file:15288kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:262144kB managed:227676kB mlocked:0kB dirty:0kB writeback:0kB mapped:3420kB shmem:11800kB slab_reclaimable:952kB slab_unreclaimable:6376kB kernel_stack:560kB pagetables:144kB unstable:0kB bounce:0kB free_pcp:792kB local_pcp:68kB free_cma:15712kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[   22.371631] lowmem_reserve[]: 0 0 0 0
[   22.375372] HighMem free:0kB min:128kB low:128kB high:128kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2883584kB managed:0kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[   22.416249] lowmem_reserve[]: 0 0 0 0
[   22.419986] DMA: 3*4kB (UEM) 4*8kB (UE) 1*16kB (M) 4*32kB (UEMC) 3*64kB (EMC) 1*128kB (E) 4*256kB (UEMC) 2*512kB (UE) 2*1024kB (MC) 4*2048kB (UEMC) 35*4096kB (MRC) = 156156kB
[   22.435922] HighMem: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
[   22.446130] 6789 total pagecache pages
[   22.449889] 0 pages in swap cache
[   22.453212] Swap cache stats: add 0, delete 0, find 0/0
[   22.458447] Free swap  = 0kB
[   22.461334] Total swap = 0kB
[   22.464222] 786432 pages RAM
[   22.467110] 720896 pages HighMem/MovableOnly
[   22.471388] 725417 pages reserved
[   22.474711] 4096 pages cma reserved
[   22.511310] big_init: I am a big module using 3932160 bytes of data!

Florian Fainelli (3):
  mm: Silence vmap() allocation failures based on caller gfp_flags
  ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
  arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

 arch/arm/kernel/module.c   | 11 +++++++++--
 arch/arm64/kernel/module.c |  7 ++++++-
 mm/vmalloc.c               |  2 +-
 3 files changed, 16 insertions(+), 4 deletions(-)

-- 
2.9.3

[PATCH v3 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

[Florian Fainelli]

If the caller has set __GFP_NOWARN don't print the following message:
vmap allocation for size 15736832 failed: use vmalloc=<size> to increase
size.

This can happen with the ARM/Linux or ARM64/Linux module loader built
with CONFIG_ARM{,64}_MODULE_PLTS=y which does a first attempt at loading
a large module from module space, then falls back to vmalloc space.

Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 0b057628a7ba..b74f1d01ef76 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -521,7 +521,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
 		}
 	}
 
-	if (printk_ratelimit())
+	if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit())
 		pr_warn("vmap allocation for size %lu failed: use vmalloc=<size> to increase size\n",
 			size);
 	kfree(va);
-- 
2.9.3

[PATCH v3 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

[Florian Fainelli]

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case by setting __GFP_NOWARN.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/kernel/module.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 80254b47dc34..3ff571c2c71c 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -40,8 +40,15 @@
 #ifdef CONFIG_MMU
 void *module_alloc(unsigned long size)
 {
-	void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
-				GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
+	gfp_t gfp_mask = GFP_KERNEL;
+	void *p;
+
+	/* Silence the initial allocation */
+	if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS))
+		gfp_mask |= __GFP_NOWARN;
+
+	p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
+				gfp_mask, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
 				__builtin_return_address(0));
 	if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
 		return p;
-- 
2.9.3

[PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

[Florian Fainelli]

When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case by setting __GFP_NOWARN.

Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm64/kernel/module.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 7f316982ce00..093c13541efb 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -32,11 +32,16 @@
 
 void *module_alloc(unsigned long size)
 {
+	gfp_t gfp_mask = GFP_KERNEL;
 	void *p;
 
+	/* Silence the initial allocation */
+	if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
+		gfp_mask |= __GFP_NOWARN;
+
 	p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
 				module_alloc_base + MODULES_VSIZE,
-				GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
+				gfp_mask, PAGE_KERNEL_EXEC, 0,
 				NUMA_NO_NODE, __builtin_return_address(0));
 
 	if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
-- 
2.9.3

Re: [PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation

[Ard Biesheuvel]

> On 27 Apr 2017, at 19:18, Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
> With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
> done from module space will fail, produce a general OOM allocation and also a
> vmap warning. The second allocation from vmalloc space may or may not be
> successful, but is actually the one we are interested about in these cases.
> 
> This patch series passed __GFP_NOWARN to silence such allocations from the
> ARM/ARM64 module loader's first time allocation when the MODULES_PLT option is
> enabled, and also makes alloc_vmap_area() react to the caller setting
> __GFP_NOWARN to silence "vmap allocation for size..." messages.
> 
> 
> Changes in v3:
> - check for __GFP_NOWARN not set where the check for printk_ratelimited()
>  is done, add Michal's Acked-by
> 
> - use C conditionals and not CPP conditionals for IS_ENABLED(), add Ard's
>  Reviewed-by tag
> 

Ok these look fine now. But are you sure that omitting the single pr_warn() gets rid of all of that?
Or do we need more patches on top?


> Changes in v2:
> 
> - check __GFP_NOWARN out of the printk_ratelimited() check (Michal)
> 
> Here is an example of what we would get without these two patches, pretty
> scary huh?
> 
> # insmod /mnt/nfs/huge.ko 
> [   22.114143] random: nonblocking pool is initialized
> [   22.183575] vmap allocation for size 15736832 failed: use vmalloc=<size> to increase size.
> [   22.191873] vmalloc: allocation failure: 15729534 bytes
> [   22.197112] insmod: page allocation failure: order:0, mode:0xd0
> [   22.203048] CPU: 2 PID: 1506 Comm: insmod Tainted: G           O    4.1.20-1.9pre-01082-gbbbff07bc3ce #9
> [   22.212536] Hardware name: Broadcom STB (Flattened Device Tree)
> [   22.218480] [<c0017eec>] (unwind_backtrace) from [<c00135c8>] (show_stack+0x10/0x14)
> [   22.226238] [<c00135c8>] (show_stack) from [<c0638684>] (dump_stack+0x90/0xa4)
> [   22.233473] [<c0638684>] (dump_stack) from [<c00aae1c>] (warn_alloc_failed+0x104/0x144)
> [   22.241490] [<c00aae1c>] (warn_alloc_failed) from [<c00d72e0>] (__vmalloc_node_range+0x170/0x218)
> [   22.250375] [<c00d72e0>] (__vmalloc_node_range) from [<c00147d0>] (module_alloc+0x50/0xac)
> [   22.258651] [<c00147d0>] (module_alloc) from [<c008ae2c>] (module_alloc_update_bounds+0xc/0x6c)
> [   22.267360] [<c008ae2c>] (module_alloc_update_bounds) from [<c008b778>] (load_module+0x8ec/0x2058)
> [   22.276329] [<c008b778>] (load_module) from [<c008cfd4>] (SyS_init_module+0xf0/0x174)
> [   22.284170] [<c008cfd4>] (SyS_init_module) from [<c0010140>] (ret_fast_syscall+0x0/0x3c)
> [   22.292277] Mem-Info:
> [   22.294567] active_anon:5236 inactive_anon:1773 isolated_anon:0
> [   22.294567]  active_file:1 inactive_file:3822 isolated_file:0
> [   22.294567]  unevictable:0 dirty:0 writeback:0 unstable:0
> [   22.294567]  slab_reclaimable:238 slab_unreclaimable:1594
> [   22.294567]  mapped:855 shmem:2950 pagetables:36 bounce:0
> [   22.294567]  free:39031 free_pcp:198 free_cma:3928
> [   22.327196] DMA free:156124kB min:1880kB low:2348kB high:2820kB active_anon:20944kB inactive_anon:7092kB active_file:4kB inactive_file:15288kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:262144kB managed:227676kB mlocked:0kB dirty:0kB writeback:0kB mapped:3420kB shmem:11800kB slab_reclaimable:952kB slab_unreclaimable:6376kB kernel_stack:560kB pagetables:144kB unstable:0kB bounce:0kB free_pcp:792kB local_pcp:68kB free_cma:15712kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [   22.371631] lowmem_reserve[]: 0 0 0 0
> [   22.375372] HighMem free:0kB min:128kB low:128kB high:128kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2883584kB managed:0kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
> [   22.416249] lowmem_reserve[]: 0 0 0 0
> [   22.419986] DMA: 3*4kB (UEM) 4*8kB (UE) 1*16kB (M) 4*32kB (UEMC) 3*64kB (EMC) 1*128kB (E) 4*256kB (UEMC) 2*512kB (UE) 2*1024kB (MC) 4*2048kB (UEMC) 35*4096kB (MRC) = 156156kB
> [   22.435922] HighMem: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> [   22.446130] 6789 total pagecache pages
> [   22.449889] 0 pages in swap cache
> [   22.453212] Swap cache stats: add 0, delete 0, find 0/0
> [   22.458447] Free swap  = 0kB
> [   22.461334] Total swap = 0kB
> [   22.464222] 786432 pages RAM
> [   22.467110] 720896 pages HighMem/MovableOnly
> [   22.471388] 725417 pages reserved
> [   22.474711] 4096 pages cma reserved
> [   22.511310] big_init: I am a big module using 3932160 bytes of data!
> 
> Florian Fainelli (3):
>  mm: Silence vmap() allocation failures based on caller gfp_flags
>  ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
>  arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
> 
> arch/arm/kernel/module.c   | 11 +++++++++--
> arch/arm64/kernel/module.c |  7 ++++++-
> mm/vmalloc.c               |  2 +-
> 3 files changed, 16 insertions(+), 4 deletions(-)
> 
> -- 
> 2.9.3
> 

Re: [PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation

[Florian Fainelli]

On 04/27/2017 11:24 AM, Ard Biesheuvel wrote:
> 
>> On 27 Apr 2017, at 19:18, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
>> done from module space will fail, produce a general OOM allocation and also a
>> vmap warning. The second allocation from vmalloc space may or may not be
>> successful, but is actually the one we are interested about in these cases.
>>
>> This patch series passed __GFP_NOWARN to silence such allocations from the
>> ARM/ARM64 module loader's first time allocation when the MODULES_PLT option is
>> enabled, and also makes alloc_vmap_area() react to the caller setting
>> __GFP_NOWARN to silence "vmap allocation for size..." messages.
>>
>>
>> Changes in v3:
>> - check for __GFP_NOWARN not set where the check for printk_ratelimited()
>>  is done, add Michal's Acked-by
>>
>> - use C conditionals and not CPP conditionals for IS_ENABLED(), add Ard's
>>  Reviewed-by tag
>>
> 
> Ok these look fine now. But are you sure that omitting the single pr_warn() gets rid of all of that?
> Or do we need more patches on top?

Since the caller now set __GFP_NOWARN, this propagates correctly to all
functions called from alloc_vmap_area() like kmalloc_node(). With the
patches applied, I only get the stuff that I would expect:

# echo 8 7 4 1 > /proc/sys/kernel/printk
# insmod huge.ko
[   59.285547] huge: loading out-of-tree module taints kernel.
[   59.328553] big_init: I am a big module using 3932160 bytes of data!
#

> 
> 
>> Changes in v2:
>>
>> - check __GFP_NOWARN out of the printk_ratelimited() check (Michal)
>>
>> Here is an example of what we would get without these two patches, pretty
>> scary huh?
>>
>> # insmod /mnt/nfs/huge.ko 
>> [   22.114143] random: nonblocking pool is initialized
>> [   22.183575] vmap allocation for size 15736832 failed: use vmalloc=<size> to increase size.
>> [   22.191873] vmalloc: allocation failure: 15729534 bytes
>> [   22.197112] insmod: page allocation failure: order:0, mode:0xd0
>> [   22.203048] CPU: 2 PID: 1506 Comm: insmod Tainted: G           O    4.1.20-1.9pre-01082-gbbbff07bc3ce #9
>> [   22.212536] Hardware name: Broadcom STB (Flattened Device Tree)
>> [   22.218480] [<c0017eec>] (unwind_backtrace) from [<c00135c8>] (show_stack+0x10/0x14)
>> [   22.226238] [<c00135c8>] (show_stack) from [<c0638684>] (dump_stack+0x90/0xa4)
>> [   22.233473] [<c0638684>] (dump_stack) from [<c00aae1c>] (warn_alloc_failed+0x104/0x144)
>> [   22.241490] [<c00aae1c>] (warn_alloc_failed) from [<c00d72e0>] (__vmalloc_node_range+0x170/0x218)
>> [   22.250375] [<c00d72e0>] (__vmalloc_node_range) from [<c00147d0>] (module_alloc+0x50/0xac)
>> [   22.258651] [<c00147d0>] (module_alloc) from [<c008ae2c>] (module_alloc_update_bounds+0xc/0x6c)
>> [   22.267360] [<c008ae2c>] (module_alloc_update_bounds) from [<c008b778>] (load_module+0x8ec/0x2058)
>> [   22.276329] [<c008b778>] (load_module) from [<c008cfd4>] (SyS_init_module+0xf0/0x174)
>> [   22.284170] [<c008cfd4>] (SyS_init_module) from [<c0010140>] (ret_fast_syscall+0x0/0x3c)
>> [   22.292277] Mem-Info:
>> [   22.294567] active_anon:5236 inactive_anon:1773 isolated_anon:0
>> [   22.294567]  active_file:1 inactive_file:3822 isolated_file:0
>> [   22.294567]  unevictable:0 dirty:0 writeback:0 unstable:0
>> [   22.294567]  slab_reclaimable:238 slab_unreclaimable:1594
>> [   22.294567]  mapped:855 shmem:2950 pagetables:36 bounce:0
>> [   22.294567]  free:39031 free_pcp:198 free_cma:3928
>> [   22.327196] DMA free:156124kB min:1880kB low:2348kB high:2820kB active_anon:20944kB inactive_anon:7092kB active_file:4kB inactive_file:15288kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:262144kB managed:227676kB mlocked:0kB dirty:0kB writeback:0kB mapped:3420kB shmem:11800kB slab_reclaimable:952kB slab_unreclaimable:6376kB kernel_stack:560kB pagetables:144kB unstable:0kB bounce:0kB free_pcp:792kB local_pcp:68kB free_cma:15712kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
>> [   22.371631] lowmem_reserve[]: 0 0 0 0
>> [   22.375372] HighMem free:0kB min:128kB low:128kB high:128kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2883584kB managed:0kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
>> [   22.416249] lowmem_reserve[]: 0 0 0 0
>> [   22.419986] DMA: 3*4kB (UEM) 4*8kB (UE) 1*16kB (M) 4*32kB (UEMC) 3*64kB (EMC) 1*128kB (E) 4*256kB (UEMC) 2*512kB (UE) 2*1024kB (MC) 4*2048kB (UEMC) 35*4096kB (MRC) = 156156kB
>> [   22.435922] HighMem: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>> [   22.446130] 6789 total pagecache pages
>> [   22.449889] 0 pages in swap cache
>> [   22.453212] Swap cache stats: add 0, delete 0, find 0/0
>> [   22.458447] Free swap  = 0kB
>> [   22.461334] Total swap = 0kB
>> [   22.464222] 786432 pages RAM
>> [   22.467110] 720896 pages HighMem/MovableOnly
>> [   22.471388] 725417 pages reserved
>> [   22.474711] 4096 pages cma reserved
>> [   22.511310] big_init: I am a big module using 3932160 bytes of data!
>>
>> Florian Fainelli (3):
>>  mm: Silence vmap() allocation failures based on caller gfp_flags
>>  ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
>>  arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
>>
>> arch/arm/kernel/module.c   | 11 +++++++++--
>> arch/arm64/kernel/module.c |  7 ++++++-
>> mm/vmalloc.c               |  2 +-
>> 3 files changed, 16 insertions(+), 4 deletions(-)
>>
>> -- 
>> 2.9.3
>>


-- 
Florian

Re: [PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

[Will Deacon]

On Thu, Apr 27, 2017 at 11:19:02AM -0700, Florian Fainelli wrote:
> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
> module space fails, because the module is too big, and then the module
> allocation is attempted from vmalloc space. Silence the first allocation
> failure in that case by setting __GFP_NOWARN.
> 
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
>  arch/arm64/kernel/module.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

I'm not sure what the merge plan is for these, but the arm64 bit here
looks fine to me:

Acked-by: Will Deacon <will.deacon@arm.com>

Will

> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 7f316982ce00..093c13541efb 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -32,11 +32,16 @@
>  
>  void *module_alloc(unsigned long size)
>  {
> +	gfp_t gfp_mask = GFP_KERNEL;
>  	void *p;
>  
> +	/* Silence the initial allocation */
> +	if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
> +		gfp_mask |= __GFP_NOWARN;
> +
>  	p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>  				module_alloc_base + MODULES_VSIZE,
> -				GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
> +				gfp_mask, PAGE_KERNEL_EXEC, 0,
>  				NUMA_NO_NODE, __builtin_return_address(0));
>  
>  	if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> -- 
> 2.9.3
> 

Re: [PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

[Florian Fainelli]

On 05/03/2017 04:18 AM, Will Deacon wrote:
> On Thu, Apr 27, 2017 at 11:19:02AM -0700, Florian Fainelli wrote:
>> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
>> module space fails, because the module is too big, and then the module
>> allocation is attempted from vmalloc space. Silence the first allocation
>> failure in that case by setting __GFP_NOWARN.
>>
>> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>>  arch/arm64/kernel/module.c | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> I'm not sure what the merge plan is for these, but the arm64 bit here
> looks fine to me:
> 
> Acked-by: Will Deacon <will.deacon@arm.com>

Thanks, not sure either, would you or Catalin want to pick this series?

> 
> Will
> 
>> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
>> index 7f316982ce00..093c13541efb 100644
>> --- a/arch/arm64/kernel/module.c
>> +++ b/arch/arm64/kernel/module.c
>> @@ -32,11 +32,16 @@
>>  
>>  void *module_alloc(unsigned long size)
>>  {
>> +	gfp_t gfp_mask = GFP_KERNEL;
>>  	void *p;
>>  
>> +	/* Silence the initial allocation */
>> +	if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
>> +		gfp_mask |= __GFP_NOWARN;
>> +
>>  	p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>>  				module_alloc_base + MODULES_VSIZE,
>> -				GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
>> +				gfp_mask, PAGE_KERNEL_EXEC, 0,
>>  				NUMA_NO_NODE, __builtin_return_address(0));
>>  
>>  	if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
>> -- 
>> 2.9.3
>>


-- 
Florian

Re: [PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

[Will Deacon]

On Fri, May 05, 2017 at 02:07:28PM -0700, Florian Fainelli wrote:
> On 05/03/2017 04:18 AM, Will Deacon wrote:
> > On Thu, Apr 27, 2017 at 11:19:02AM -0700, Florian Fainelli wrote:
> >> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
> >> module space fails, because the module is too big, and then the module
> >> allocation is attempted from vmalloc space. Silence the first allocation
> >> failure in that case by setting __GFP_NOWARN.
> >>
> >> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >>  arch/arm64/kernel/module.c | 7 ++++++-
> >>  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > I'm not sure what the merge plan is for these, but the arm64 bit here
> > looks fine to me:
> > 
> > Acked-by: Will Deacon <will.deacon@arm.com>
> 
> Thanks, not sure either, would you or Catalin want to pick this series?

We'd need an Ack from Russell on the arch/arm/ part before we could take
this series.

Will

Re: [PATCH v3 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

[Florian Fainelli]

On 04/27/2017 11:19 AM, Florian Fainelli wrote:
> When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the
> module space fails, because the module is too big, and then the module
> allocation is attempted from vmalloc space. Silence the first allocation
> failure in that case by setting __GFP_NOWARN.

Russell, are you okay with this change? Do you have a preference as
which tree should carry this patch series?

Thanks

> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
>  arch/arm/kernel/module.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
> index 80254b47dc34..3ff571c2c71c 100644
> --- a/arch/arm/kernel/module.c
> +++ b/arch/arm/kernel/module.c
> @@ -40,8 +40,15 @@
>  #ifdef CONFIG_MMU
>  void *module_alloc(unsigned long size)
>  {
> -	void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
> -				GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
> +	gfp_t gfp_mask = GFP_KERNEL;
> +	void *p;
> +
> +	/* Silence the initial allocation */
> +	if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS))
> +		gfp_mask |= __GFP_NOWARN;
> +
> +	p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
> +				gfp_mask, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
>  				__builtin_return_address(0));
>  	if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
>  		return p;
> 


-- 
Florian

Re: [PATCH v3 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

[Russell King - ARM Linux]

On Tue, May 09, 2017 at 04:16:09PM -0700, Florian Fainelli wrote:
> On 04/27/2017 11:19 AM, Florian Fainelli wrote:
> > When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the
> > module space fails, because the module is too big, and then the module
> > allocation is attempted from vmalloc space. Silence the first allocation
> > failure in that case by setting __GFP_NOWARN.
> 
> Russell, are you okay with this change? Do you have a preference as
> which tree should carry this patch series?

It looks sensible.

Acked-by: Russell King <rmk+kernel@armlinux.org.uk>

No preference which tree it goes through...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

[Catalin Marinas]

On Mon, May 08, 2017 at 11:07:24AM +0100, Will Deacon wrote:
> On Fri, May 05, 2017 at 02:07:28PM -0700, Florian Fainelli wrote:
> > On 05/03/2017 04:18 AM, Will Deacon wrote:
> > > On Thu, Apr 27, 2017 at 11:19:02AM -0700, Florian Fainelli wrote:
> > >> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
> > >> module space fails, because the module is too big, and then the module
> > >> allocation is attempted from vmalloc space. Silence the first allocation
> > >> failure in that case by setting __GFP_NOWARN.
> > >>
> > >> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > >> ---
> > >>  arch/arm64/kernel/module.c | 7 ++++++-
> > >>  1 file changed, 6 insertions(+), 1 deletion(-)
> > > 
> > > I'm not sure what the merge plan is for these, but the arm64 bit here
> > > looks fine to me:
> > > 
> > > Acked-by: Will Deacon <will.deacon@arm.com>
> > 
> > Thanks, not sure either, would you or Catalin want to pick this series?
> 
> We'd need an Ack from Russell on the arch/arm/ part before we could take
> this series.

The first patch touches mm/vmalloc.c, so we could also merge the series
via akpm's tree. Andrew, do you have any preference?

-- 
Catalin

Re: [PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

[Will Deacon]

On Wed, May 10, 2017 at 09:38:03AM +0100, Catalin Marinas wrote:
> On Mon, May 08, 2017 at 11:07:24AM +0100, Will Deacon wrote:
> > On Fri, May 05, 2017 at 02:07:28PM -0700, Florian Fainelli wrote:
> > > On 05/03/2017 04:18 AM, Will Deacon wrote:
> > > > On Thu, Apr 27, 2017 at 11:19:02AM -0700, Florian Fainelli wrote:
> > > >> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
> > > >> module space fails, because the module is too big, and then the module
> > > >> allocation is attempted from vmalloc space. Silence the first allocation
> > > >> failure in that case by setting __GFP_NOWARN.
> > > >>
> > > >> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > > >> ---
> > > >>  arch/arm64/kernel/module.c | 7 ++++++-
> > > >>  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > 
> > > > I'm not sure what the merge plan is for these, but the arm64 bit here
> > > > looks fine to me:
> > > > 
> > > > Acked-by: Will Deacon <will.deacon@arm.com>
> > > 
> > > Thanks, not sure either, would you or Catalin want to pick this series?
> > 
> > We'd need an Ack from Russell on the arch/arm/ part before we could take
> > this series.
> 
> The first patch touches mm/vmalloc.c, so we could also merge the series
> via akpm's tree. Andrew, do you have any preference?

Michal Hocko acked that one, so I think we can take the whole series via
arm64.

Will

Re: [PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

[Catalin Marinas]

On Wed, May 10, 2017 at 12:55:12PM +0100, Will Deacon wrote:
> On Wed, May 10, 2017 at 09:38:03AM +0100, Catalin Marinas wrote:
> > On Mon, May 08, 2017 at 11:07:24AM +0100, Will Deacon wrote:
> > > On Fri, May 05, 2017 at 02:07:28PM -0700, Florian Fainelli wrote:
> > > > On 05/03/2017 04:18 AM, Will Deacon wrote:
> > > > > On Thu, Apr 27, 2017 at 11:19:02AM -0700, Florian Fainelli wrote:
> > > > >> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
> > > > >> module space fails, because the module is too big, and then the module
> > > > >> allocation is attempted from vmalloc space. Silence the first allocation
> > > > >> failure in that case by setting __GFP_NOWARN.
> > > > >>
> > > > >> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > > >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > > > >> ---
> > > > >>  arch/arm64/kernel/module.c | 7 ++++++-
> > > > >>  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > > 
> > > > > I'm not sure what the merge plan is for these, but the arm64 bit here
> > > > > looks fine to me:
> > > > > 
> > > > > Acked-by: Will Deacon <will.deacon@arm.com>
> > > > 
> > > > Thanks, not sure either, would you or Catalin want to pick this series?
> > > 
> > > We'd need an Ack from Russell on the arch/arm/ part before we could take
> > > this series.
> > 
> > The first patch touches mm/vmalloc.c, so we could also merge the series
> > via akpm's tree. Andrew, do you have any preference?
> 
> Michal Hocko acked that one, so I think we can take the whole series via
> arm64.

OK. I'll send the patches for -rc1.

Thanks.

-- 
Catalin