From: Ralf Baechle <ralf@linux-mips.org>
To: Veli-Pekka Peltola <veli-pekka.peltola@bluegiga.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mips@linux-mips.org,
Russell King <linux@arm.linux.org.uk>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v2] mm: module_alloc: check if size is 0
Date: Thu, 27 Jun 2013 11:39:17 +0200 [thread overview]
Message-ID: <20130627093917.GQ7171@linux-mips.org> (raw)
In-Reply-To: <1331125768-25454-1-git-send-email-veli-pekka.peltola@bluegiga.com>
Warming up an ancient thread because the discussion seems to have just
stalled at some point and I still have this patch bitrotting in patchwork.
The original thread can be found at:
http://www.linux-mips.org/archives/linux-mips/2012-03/msg00006.html
http://www.linux-mips.org/archives/linux-mips/2012-03/msg00028.html
On Wed, Mar 07, 2012 at 03:09:28PM +0200, Veli-Pekka Peltola wrote:
> After commit de7d2b567d040e3b67fe7121945982f14343213d (mm/vmalloc.c: report
> more vmalloc failures) users will get a warning if vmalloc_node_range() is
> called with size 0. This happens if module's init size equals to 0. This
> patch changes ARM, MIPS and x86 module_alloc() to return NULL before calling
> vmalloc_node_range() that would also return NULL and print a warning.
>
> Signed-off-by: Veli-Pekka Peltola <veli-pekka.peltola@bluegiga.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> ---
> I found this with ARM but after checking out various implementations of
> module_alloc() I thought it would be better to fix all at once.
>
> One way to replicate the warning:
> compile kernel with CONFIG_KALLSYMS=n
> insmod a module without init, I used usb-common.ko
I didn't try to reproduce the issue but the code in question doesn't seem
to have changed so the issue should still persist.
Imho de7d2b567d040e3b67fe7121945982f14343213d [mm/vmalloc.c: report more
vmalloc failures] is overly strict in that it also reports zero-sized
allocations. I consider such allocations stupid but legitimiate and often
better preferrable over having to scatter checks for zero size all over
place. So maybe something like below patch?
Thanks,
Ralf
---
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
mm/vmalloc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index d365724..e58ca10 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1679,7 +1679,10 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align,
unsigned long real_size = size;
size = PAGE_ALIGN(size);
- if (!size || (size >> PAGE_SHIFT) > totalram_pages)
+ if (unlikely(!size))
+ return NULL;
+
+ if ((size >> PAGE_SHIFT) > totalram_pages)
goto fail;
area = __get_vm_area_node(size, align, VM_ALLOC | VM_UNLIST,
@@ -1711,6 +1714,7 @@ fail:
warn_alloc_failed(gfp_mask, 0,
"vmalloc: allocation failure: %lu bytes\n",
real_size);
+
return NULL;
}
WARNING: multiple messages have this Message-ID (diff)
From: ralf@linux-mips.org (Ralf Baechle)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] mm: module_alloc: check if size is 0
Date: Thu, 27 Jun 2013 11:39:17 +0200 [thread overview]
Message-ID: <20130627093917.GQ7171@linux-mips.org> (raw)
In-Reply-To: <1331125768-25454-1-git-send-email-veli-pekka.peltola@bluegiga.com>
Warming up an ancient thread because the discussion seems to have just
stalled at some point and I still have this patch bitrotting in patchwork.
The original thread can be found at:
http://www.linux-mips.org/archives/linux-mips/2012-03/msg00006.html
http://www.linux-mips.org/archives/linux-mips/2012-03/msg00028.html
On Wed, Mar 07, 2012 at 03:09:28PM +0200, Veli-Pekka Peltola wrote:
> After commit de7d2b567d040e3b67fe7121945982f14343213d (mm/vmalloc.c: report
> more vmalloc failures) users will get a warning if vmalloc_node_range() is
> called with size 0. This happens if module's init size equals to 0. This
> patch changes ARM, MIPS and x86 module_alloc() to return NULL before calling
> vmalloc_node_range() that would also return NULL and print a warning.
>
> Signed-off-by: Veli-Pekka Peltola <veli-pekka.peltola@bluegiga.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86 at kernel.org
> ---
> I found this with ARM but after checking out various implementations of
> module_alloc() I thought it would be better to fix all at once.
>
> One way to replicate the warning:
> compile kernel with CONFIG_KALLSYMS=n
> insmod a module without init, I used usb-common.ko
I didn't try to reproduce the issue but the code in question doesn't seem
to have changed so the issue should still persist.
Imho de7d2b567d040e3b67fe7121945982f14343213d [mm/vmalloc.c: report more
vmalloc failures] is overly strict in that it also reports zero-sized
allocations. I consider such allocations stupid but legitimiate and often
better preferrable over having to scatter checks for zero size all over
place. So maybe something like below patch?
Thanks,
Ralf
---
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
mm/vmalloc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index d365724..e58ca10 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1679,7 +1679,10 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align,
unsigned long real_size = size;
size = PAGE_ALIGN(size);
- if (!size || (size >> PAGE_SHIFT) > totalram_pages)
+ if (unlikely(!size))
+ return NULL;
+
+ if ((size >> PAGE_SHIFT) > totalram_pages)
goto fail;
area = __get_vm_area_node(size, align, VM_ALLOC | VM_UNLIST,
@@ -1711,6 +1714,7 @@ fail:
warn_alloc_failed(gfp_mask, 0,
"vmalloc: allocation failure: %lu bytes\n",
real_size);
+
return NULL;
}
next prev parent reply other threads:[~2013-06-27 9:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-01 19:45 [PATCH] mm: module_alloc: check if size is 0 Veli-Pekka Peltola
2012-03-01 19:45 ` Veli-Pekka Peltola
2012-03-01 20:46 ` H. Peter Anvin
2012-03-01 20:46 ` H. Peter Anvin
2012-03-07 13:09 ` [PATCH v2] " Veli-Pekka Peltola
2012-03-07 13:09 ` Veli-Pekka Peltola
2012-03-19 15:36 ` Veli-Pekka Peltola
2012-03-19 15:36 ` Veli-Pekka Peltola
2013-06-27 9:39 ` Ralf Baechle [this message]
2013-06-27 9:39 ` Ralf Baechle
2013-06-27 22:23 ` Andrew Morton
2013-06-27 22:23 ` Andrew Morton
2013-06-27 22:46 ` Joe Perches
2013-06-27 22:46 ` Joe Perches
2013-07-01 3:18 ` Rusty Russell
2013-07-01 3:18 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130627093917.GQ7171@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux@arm.linux.org.uk \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=veli-pekka.peltola@bluegiga.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.