Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1477528

[PATCH] ARM: module: suppress misleading allocation failure warning

Path csiph.com!news.mixmin.net!aioe.org!gothmog.csi.it!bofh.it!news.nic.it!robomod
From "Wiebe, Wladislav (Nokia - DE/Ulm)" <wladislav.wiebe@nokia.com>
Newsgroups linux.kernel
Subject [PATCH] ARM: module: suppress misleading allocation failure warning
Date Tue, 06 Sep 2016 17:30:02 +0200
Message-ID <seqtY-3JB-65@gated-at.bofh.it> (permalink)
X-Greylist delayed 947 seconds by postgrey-1.27 at vger.kernel.org; Tue, 06 Sep 2016 11:23:35 EDT
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QL9nWSBCbQuM2BA41LhswRrPKN3kFnrkbJDT2dgdERs=; b=QzX87oatCWiQOvWDc0yhlHO0W+a09uXXCMp/1Za2W3S2w3ABwQAftvWXupKiUbsqO5Dshf0k/lIsfYGvbAc48YohdOxUGsdk05RPncmMZPrEZYGLvmpULiGajTKrHSrsSZbCs7bwhtZLpskx3DX2mBIzxaXmhgySe61Mnvg1go0=
Thread-Topic [PATCH] ARM: module: suppress misleading allocation failure warning
Thread-Index AdIIUGqzccbOP3gHSQyn95xzy8yirQ==
Accept-Language de-DE, en-US
Content-Language en-US
Authentication-Results spf=none (sender IP is ) smtp.mailfrom=wladislav.wiebe@nokia.com;
X-Originating-IP [131.228.2.21]
X-Ms-Office365-Filtering-Correlation-ID 616d6922-d00b-40fb-e6a6-08d3d6678e89
X-Microsoft-Exchange-Diagnostics 1;HE1PR07MB1483;6:BFzCyAQ1VsX95duUhXVUXjqhfxjoHLxys6Eq43yaGOdZK/7sBncFvDfrlYws7iFtSoCxGFXcbvYjn5hCjDLE3YAARP4lLnX9MrgtWOGjuYh+EYKaWBmSLy66RqR1XI53FZklchlGztPUqR5vXYVg2ZhW93TI1AeOhRuMM2VPpD+Qh5O5fmsFDssTvLwJfLj/2CB9G2N3q7ei0vHVF7OL9xPX0Rpp2nqc/KPS0bCjqEHyLsALDbAPQUzC9hcNk2u5+TFq7jjNVlkGvPh76QlWcdmx5q3HCXGeafu0ONgOpz65sMDPgSdWt76QszR8Lz5FgGY/zeCh4NND+eOwdtvalA==;5:x5NtPLZCXfEaDcwRvSaU5pIXBOiHlmDHxYZDniNAnnWRpyt8BzB8JVV63lxcCCLmWQUth9K69fZzqskfBJcR08dDJi3J2lXzV4hXGPRPFDyp0EiFDB2P7yDInSVvVZ8PZoqvOV+VQ4sR8yV4qBahUw==;24:BENSXBSHeJiriFIkQXJGkMKrmsDBQEFXrxtJjHgLck8V+KI76fbEz60/pk0IlIt50NhzRlagnpZ+8vWUIker/d4fQqBFnEXhcWh7JTbUV9c=;7:5tBCtgvCk6+NS7kUxXtPzxlN0IlDgoz2O6xpNxRAEQvlPjIUOZU2Eh84sLUP2Fg3GXXuXluMhVNurDp3XNSJ23Cbg0MGrUCrsiCQavJ84/stcB7uRPQIV+holipCH12V1Tb4vTNt7FuWZjT7nnl2tMSJPrjHsMOMjUmoyCe67L1qaA/IYTIXMnQnsNI7TE3A1/ndwPlhG3TDrJHkrV0A8i5ppu9lfixF91zX3tMf1j6rAq+SZUzEAtvUPvUelyGm
X-Microsoft-Antispam UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1483;
X-Microsoft-Antispam-Prvs <HE1PR07MB14836D3D69815136E49B7BBEFAF90@HE1PR07MB1483.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test UriScan:(82608151540597)(211171220733660)(17755550239193);
X-Exchange-Antispam-Report-Cfa-Test BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);SRVR:HE1PR07MB1483;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1483;
X-Forefront-Prvs 0057EE387C
X-Forefront-Antispam-Report SFV:NSPM;SFS:(10019020)(6009001)(7916002)(199003)(189002)(8676002)(7846002)(81156014)(305945005)(122556002)(229853001)(10400500002)(7736002)(7696003)(74316002)(86362001)(189998001)(33656002)(5660300001)(2201001)(77096005)(5001770100001)(92566002)(87936001)(68736007)(19580405001)(3660700001)(5002640100001)(66066001)(2501003)(8936002)(105586002)(9686002)(4326007)(101416001)(19580395003)(106356001)(2906002)(97736004)(6116002)(586003)(3846002)(3280700002)(11100500001)(81166006)(102836003)(76576001)(54356999)(2900100001)(50986999)(21314002);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR07MB1483;H:HE1PR07MB1483.eurprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en;
Received-Spf None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
Spamdiagnosticoutput 1:99
Spamdiagnosticmetadata NSPM
Content-Type text/plain; charset="us-ascii"
Content-Transfer-Encoding quoted-printable
MIME-Version 1.0
X-Originatororg nokia.com
X-Ms-Exchange-Crosstenant-Originalarrivaltime 06 Sep 2016 15:07:44.8387 (UTC)
X-Ms-Exchange-Crosstenant-Fromentityheader Hosted
X-Ms-Exchange-Crosstenant-ID 5d471751-9675-428d-917b-70f44f9630b0
X-Ms-Exchange-Transport-Crosstenantheadersstamped HE1PR07MB1483
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 65
Organization linux.* mail to news gateway
X-Original-Cc "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
X-Original-Date Tue, 6 Sep 2016 15:07:44 +0000
X-Original-Message-ID <HE1PR07MB1483029049CF1F5663C96404FAF90@HE1PR07MB1483.eurprd07.prod.outlook.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1477528

Show key headers only | View raw


in case __vmalloc_node_range fails to allocate memory inside
of MODULES_VADDR <-> MODULES_END range, it suggests
to increase vmalloc size, like reported below:
..
[   41.526591] vmap allocation for size 65536 failed: use vmalloc=<size> to increase size.
[   41.526597] vmalloc: allocation failure: 58712 bytes
[   41.526602] systemd-udevd: page allocation failure: order:0, mode:0xd0
[   41.526610] CPU: 2 PID: 2782 Comm: systemd-udevd Tainted: G           O xxx #1
[   41.526628] [<c0413615>] (unwind_backtrace) from [<c04106d9>] (show_stack+0x11/0x14)
[   41.526640] [<c04106d9>] (show_stack) from [<c0765745>] (dump_stack+0x7f/0xa2)
[   41.526651] [<c0765745>] (dump_stack) from [<c049fcb1>] (warn_alloc_failed+0x85/0xbc)
[   41.526664] [<c049fcb1>] (warn_alloc_failed) from [<c04c1f49>] (__vmalloc_node_range+0xed/0x188)
[   41.526673] [<c04c1f49>] (__vmalloc_node_range) from [<c0410ea7>] (module_alloc+0x47/0x8c)
[   41.526684] [<c0410ea7>] (module_alloc) from [<c046755b>] (module_alloc_update_bounds+0xf/0x64)
[   41.526692] [<c046755b>] (module_alloc_update_bounds) from [<c0467fd7>] (load_module+0xa27/0x19b4)
[   41.526700] [<c0467fd7>] (load_module) from [<c0469089>] (SyS_finit_module+0x59/0x84)
[   41.526709] [<c0469089>] (SyS_finit_module) from [<c040d8c1>] (ret_fast_syscall+0x1/0x64)
..

This is obviously wrong, as increasing vmalloc size will not
help in this case. We should suppress the warning and keep
it only reporting in PLT case, where it afterwards really tries to
allocate module memory in the VMALLOC space.

Signed-off-by: Wladislav Wiebe <wladislav.wiebe@nokia.com>
Tested-by: Wladislav Wiebe <wladislav.wiebe@nokia.com>
---
There might a more advanced solution possible, like to pass
an additional flag to the allocator for indicating that there
is a call from module_alloc and handle the allocation failure message
differently. But I am not sure if such a solution would
be to oversized for this purpose, as modprobe should fail in
case allocation fails for the module.

 arch/arm/kernel/module.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 4f14b5c..724447b 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -41,8 +41,8 @@
 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,
-				__builtin_return_address(0));
+				GFP_KERNEL | __GFP_NOWARN, PAGE_KERNEL_EXEC, 0,
+				NUMA_NO_NODE, __builtin_return_address(0));
 	if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
 		return p;
 	return __vmalloc_node_range(size, 1,  VMALLOC_START, VMALLOC_END,
-- 
1.7.12.4

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

[PATCH] ARM: module: suppress misleading allocation failure warning "Wiebe, Wladislav (Nokia - DE/Ulm)" <wladislav.wiebe@nokia.com> - 2016-09-06 17:30 +0200

csiph-web