Our customer experienced a kernel panic after a kernel upgrade on the node boot stage.

Kernel panic calltrace (process - 'modprobe'):

flush_workqueue
destroy_workqueue
bond_destructor
netdev_run_todo
bonding_init
sys_init_module

The affected kernel is based on 2.6.18-194.3.1.el5.

Checking the code:
destroy_workqueue() is called in bonding_init() on err path AND in bond_destructor() one after another.

This issue has been already fixed in mainstream:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d34d1a20e8171be819a6c8c4de4eea6104d174e

----
bonding: fix panic if initialization fails

If module initialisation failed (e.g. because the bonding sysfs entry
cannot be created), kernel panics:
 IP: [<ffffffff8024910a>] destroy_workqueue+0x2d/0x146
Call Trace:
 [<ffffffff808268c4>] bond_destructor+0x28/0x78
 [<ffffffff80b64471>] netdev_run_todo+0x231/0x25a
 [<ffffffff80b6dbcd>] rtnl_unlock+0x9/0xb
 [<ffffffff81567907>] bonding_init+0x83e/0x84a

Remove the calls to bond_work_cancel_all() and destroy_workqueue();
both are also called/scheduled via bond_free_all().

bond_destroy_sysfs is unecessary because the sysfs entry has
not been created in the error case.

Signed-off-by: Florian Westphal <fw>
Signed-off-by: Jay Vosburgh <fubar.com>
Signed-off-by: Jiri Pirko <jpirko>
Signed-off-by: David S. Miller <davem>
----

Please, apply the patch too.

Thank you.

--
Best regards,

Konstantin Khorenko,
PVCfL/OpenVZ developer,
Parallels