gack, why doesn't the backtrace show the kernel symbols?

Please check that CONFIG_KALLSYMS is enabled, then retry?

Hi Andrew
confirmed for 3.2.14.
This allocation failure appears only _without_ CONFIG_KALLSYMS=y.

"http://forums.gentoo.org/viewtopic-t-908032.html"
"http://openelec.tv/forum/90-miscellaneous/25154-solved-udevd-page-allocation-failure"

Slim kernel user folks disabling CONFIG_KALLSYMS to save some bytes. :)

Regression must be between v3.1 and v3.2-rc1.
Following modules are compiled:
CONFIG_CFG80211=m
CONFIG_MAC80211=m
CONFIG_SCSI_WAIT_SCAN=m
CONFIG_ATH_COMMON=m
CONFIG_ATH9K_HW=m
CONFIG_ATH9K_COMMON=m
CONFIG_ATH9K=m

It can't be a modprobe binary/userland problem. Cross test with modules of used components and in-kernel wlan stuff don't show this error.

Strip down more modules. Even with that module config this error occurs.
CONFIG_SCSI_WAIT_SCAN=m
CONFIG_ATH_COMMON=m
CONFIG_ATH9K_HW=m
CONFIG_ATH9K_COMMON=m
CONFIG_ATH9K=m

So our error must in ath9k driver code.

Same happen with kernel v3.4.3.

For now I using no ath9k modules anymore.
I get rig of this allocation failure oops and replace wireless-regdb/crda userland rubbish by enabling CONFIG_CFG80211_INTERNAL_REGDB.
Initramfs is small and clean again and "iw reg set" works afterwards in userland linux also.

Same happens starting with 3.2-rc's, and I'm _not_ using ath9k module, this happens with bunch of other modules.

nzqr: Please attach the dmesg trace after it occurs. Without that nothing can be debugged

Yes, this is very simple: some driver is asking vmalloc() to allocate zero bytes, which is daft.  We just need to find out which driver is doing this and for that, we need some sort of backtrace.

We could probably work it out if we just knew the arguments to that modprobe invokation, sigh.

I have fixed this on my system by following a forum post:
https://bbs.archlinux.org/viewtopic.php?pid=1142013#p1142013

Basically, with CONFIG_KALLSYMS=n, some modules have an init_size of zero, but kernel/module.c still attempts to do the vmalloc of zero bytes which triggers the error and the dump.

I'm no expert, but it seems to me that init_size == 0 is probably OK for a module? On my system, I was getting dumps from about half a dozen disparate module insertions from boot or inserting a peripheral.

Obviously, the workaround is to set CONFIG_KALLSYMS=y!

The warning is harmless, but I've hoisted the old 0-len test into kernel/module.c.

The don't-call-vmalloc-with-0-size patch was removed from various archs in:

commit d0a21265dfb5fa8ae54e90d0fb6d1c215b10a28a
Author: David Rientjes <rientjes@google.com>
Date:   Thu Jan 13 15:46:02 2011 -0800

    mm: unify module_alloc code for vmalloc
    
    Four architectures (arm, mips, sparc, x86) use __vmalloc_area() for
    module_init().  Much of the code is duplicated and can be generalized in a
    globally accessible function, __vmalloc_node_range().
    
    __vmalloc_node() now calls into __vmalloc_node_range() with a range of
    [VMALLOC_START, VMALLOC_END) for functionally equivalent behavior.
    
    Each architecture may then use __vmalloc_node_range() directly to remove
    the duplication of code.

Then you signed-off a "cleanup" which caused the spurious warning in:

commit de7d2b567d040e3b67fe7121945982f14343213d
Author: Joe Perches <joe@perches.com>
Date:   Mon Oct 31 17:08:48 2011 -0700

    mm/vmalloc.c: report more vmalloc failures
    
    Some vmalloc failure paths do not report OOM conditions.
    
    Add warn_alloc_failed, which also does a dump_stack, to those failure
    paths.
    
    This allows more site specific vmalloc failure logging message printks to
    be removed.
    
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

A patch referencing this bug report has been merged in Linux v3.8-rc1:

commit 82fab442f5322b016f72891c0db2436c6a6c20b7
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Tue Dec 11 09:38:33 2012 +1030

    modules: don't hand 0 to vmalloc.