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
| ||
|
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