Patchwork 2.6.33 dies on modprobe

login
register
mail settings
Submitter WANG Cong
Date March 3, 2010, 8:58 a.m.
Message ID <2375c9f91003030058h7456b5e1odc8ca958f5af2c0d@mail.gmail.com>
Download mbox | patch
Permalink /patch/46784/
State RFC
Delegated to: David Miller
Headers show

Comments

WANG Cong - March 3, 2010, 8:58 a.m.
On Mon, Mar 1, 2010 at 5:07 PM, M G Berberich
<berberic@fmi.uni-passau.de> wrote:
> Hello,
>
> Am Montag, den 01. März schrieb Américo Wang:
>> On Mon, Mar 1, 2010 at 6:12 AM, M G Berberich
>> <berberic@fmi.uni-passau.de> wrote:
>
>> > I tried to build a 2.6.33 kernel but on boot it dies on modprobe
>> > (kernel-Oops). This might be the result of faulty config, but I'm
>> > totaly clueless what's the fault.
>> >
>> > The kernel starts up fine and mounts the root-filesystem, but then
>> > dies on the first modprobe executed. I can boot it with init=/bin/bash
>> > and get a working bash (until I do modprobe on any module).
>> >
>> > System is a Gigabyte M55S-S3 rev 2.0 (nForce 550) with an AMD Athlon64
>> > X2 5000+ and amd64-kernel architecture. kernel-sources are from
>> > kernel.org.
>
>> It seems something is wrong with forcedeth code or PCI code.
>> Adding some Cc's.
>
> I don't think it's forcedeth. forcedeth just happens to be the first
> module that get's loaded in startup. It crashes with any other module
> too (I tried ohci_hcd).
>

Ok, below is my patch, I am not sure it could fix the BUG for you,
but it could fix the WARNING. But perhaps they are related.

Please give it a try.

--------------------->

It looks really odd that we do class_put() in non-failure path of
class_register(), shouldn't it be in class_unregister()?
In fact we have this problem long time ago, since commit 7c71448b,
but a recent change (commit 18d19c964) uncovers this.

Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>

---
WANG Cong - March 3, 2010, 9:08 a.m.
On Wed, Mar 3, 2010 at 4:58 PM, Américo Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 5:07 PM, M G Berberich
> <berberic@fmi.uni-passau.de> wrote:
>> Hello,
>>
>> Am Montag, den 01. März schrieb Américo Wang:
>>> On Mon, Mar 1, 2010 at 6:12 AM, M G Berberich
>>> <berberic@fmi.uni-passau.de> wrote:
>>
>>> > I tried to build a 2.6.33 kernel but on boot it dies on modprobe
>>> > (kernel-Oops). This might be the result of faulty config, but I'm
>>> > totaly clueless what's the fault.
>>> >
>>> > The kernel starts up fine and mounts the root-filesystem, but then
>>> > dies on the first modprobe executed. I can boot it with init=/bin/bash
>>> > and get a working bash (until I do modprobe on any module).
>>> >
>>> > System is a Gigabyte M55S-S3 rev 2.0 (nForce 550) with an AMD Athlon64
>>> > X2 5000+ and amd64-kernel architecture. kernel-sources are from
>>> > kernel.org.
>>
>>> It seems something is wrong with forcedeth code or PCI code.
>>> Adding some Cc's.
>>
>> I don't think it's forcedeth. forcedeth just happens to be the first
>> module that get's loaded in startup. It crashes with any other module
>> too (I tried ohci_hcd).
>>
>
> Ok, below is my patch, I am not sure it could fix the BUG for you,
> but it could fix the WARNING. But perhaps they are related.
>
> Please give it a try.
>

Oops! Ignore the patch, it should not be correct, I will send a
correct version soon.
Sorry.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/base/class.c b/drivers/base/class.c
index 6e2c3b0..ccf312d 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -192,7 +192,6 @@  int __class_register(struct class *cls, struct lock_class_key *key)
 		return error;
 	}
 	error = add_class_attrs(class_get(cls));
-	class_put(cls);
 	return error;
 }
 EXPORT_SYMBOL_GPL(__class_register);
@@ -200,6 +199,7 @@  EXPORT_SYMBOL_GPL(__class_register);
 void class_unregister(struct class *cls)
 {
 	pr_debug("device class '%s': unregistering\n", cls->name);
+	class_put(cls);
 	remove_class_attrs(cls);
 	kset_unregister(&cls->p->class_subsys);
 }