]> git.karo-electronics.de Git - karo-tx-linux.git/commit
module: put modules in list much earlier.
authorRusty Russell <rusty@rustcorp.com.au>
Sat, 12 Jan 2013 02:57:34 +0000 (13:27 +1030)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 28 Jan 2013 04:49:02 +0000 (20:49 -0800)
commitf9586ddba7b93ea72190f79c82079cbfc4bb8730
tree7bae4de6c86746a59de7f3e8c66c161fd4021370
parent27fb20cc5a25acbc5396adfe286e3e5fc0befaf9
module: put modules in list much earlier.

commit 1fb9341ac34825aa40354e74d9a2c69df7d2c304 upstream.

Prarit's excellent bug report:
> In recent Fedora releases (F17 & F18) some users have reported seeing
> messages similar to
>
> [   15.478160] kvm: Could not allocate 304 bytes percpu data
> [   15.478174] PERCPU: allocation failed, size=304 align=32, alloc from
> reserved chunk failed
>
> during system boot.  In some cases, users have also reported seeing this
> message along with a failed load of other modules.
>
> What is happening is systemd is loading an instance of the kvm module for
> each cpu found (see commit e9bda3b).  When the module load occurs the kernel
> currently allocates the modules percpu data area prior to checking to see
> if the module is already loaded or is in the process of being loaded.  If
> the module is already loaded, or finishes load, the module loading code
> releases the current instance's module's percpu data.

Now we have a new state MODULE_STATE_UNFORMED, we can insert the
module into the list (and thus guarantee its uniqueness) before we
allocate the per-cpu region.

Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Tested-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kernel/module.c
lib/bug.c