linux-kernel - Re: 2.6.33 dies on modprobe

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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)