linux-kernel - Fix for OpenSUSE kernel bug (was Re: [Opps] Invalid opcode)

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: <456E7DE2.5070808@vmware.com>
Date:	Wed, 29 Nov 2006 22:44:50 -0800
From:	Zachary Amsden <zach@...are.com>
To:	caglar@...dus.org.tr
Cc:	Andi Kleen <ak@...e.de>, linux-kernel@...r.kernel.org,
	Gerd Hoffmann <kraxel@...e.de>, Andrew Morton <akpm@...l.org>,
	Daniel Hecht <dhecht@...are.com>,
	Sahil Rihan <srihan@...are.com>,
	Trampus Richmond <trampus@...are.com>, betts@...are.com
Subject: Fix for OpenSUSE kernel bug (was Re: [Opps] Invalid opcode)

S.Çağlar Onur wrote:
> 05 Kas 2006 Paz 18:40 tarihinde, Andi Kleen şunları yazmıştı: 
>   
>> How do you know this?
>>     
>
> Just guessing, if im not wrong panics occur after SMP alternative switching 
> code done its job.
>
>   
>> And does it still happen in 2.6.19-rc4?
>>     
>
> Will try
>
>   
>>> in VmWare and Microsoft Virtual
>>> PC and in order to confirm this bug is not our distro specific i
>>> downloaded and tried latest OpenSuse also [1]  and [2] are screens
>>> captured by vmware but exact same panic occurs in Virtual PC as reported
>>> to us in [3].
>>>       
>> Always the same BUG()?
>>     
>
> Yes, same bug
>
>   
>> There is just some rolling Turkish text there.
>>     
>
> Ah im sorry here is the correct links :(
>
> [1] http://cekirdek.pardus.org.tr/~caglar/2.6.18/panic_on_opensuse.png
> [2] http://cekirdek.pardus.org.tr/~caglar/2.6.18/panic_on_pardus.png
>
> Cheers
>   

I'm proposing this as a fix for your bug. Having tasklets scheduled 
before softirqd gets to run might be somewhat backwards, but there is 
nothing I can find wrong about it from a correctness point of view. 
Better to boot the kernel even when compiled with bug checking on, I think.

This bug started becoming apparent in 2.6.18 because of some rework with 
the CPU hotplug code, but in theory, it exists at least all the way back 
to 2.6.10, which is as far as I looked backwards in time.

Zach

View attachment "fix-softirq-race" of type "text/plain" (1619 bytes)