lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2375c9f91003030058h7456b5e1odc8ca958f5af2c0d@mail.gmail.com>
Date:	Wed, 3 Mar 2010 16:58:12 +0800
From:	Américo Wang <xiyou.wangcong@...il.com>
To:	Américo Wang <xiyou.wangcong@...il.com>,
	linux-kernel@...r.kernel.org,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: 2.6.33 dies on modprobe

On Mon, Mar 1, 2010 at 5:07 PM, M G Berberich
<berberic@....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@....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@...il.com>
Cc: Greg Kroah-Hartman <gregkh@...e.de>

---

View attachment "drivers-base-class_c-move-class_put.diff" of type "text/plain" (621 bytes)

Powered by blists - more mailing lists