linux-kernel - Re: Linux 2.6.20-rc2

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:	Tue, 26 Dec 2006 08:20:42 -0600
From:	florin@...ha.net (Florin Iucha)
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.20-rc2

On Tue, Dec 26, 2006 at 01:40:19PM +0100, Ingo Molnar wrote:
> 
> * Andrew Morton <akpm@...l.org> wrote:
> 
> > > [ 2844.871895] BUG: scheduling while atomic: cp/0x20000000/2965
> 
> > This is the second report we've had where bit 29 of ->preempt_count is 
> > getting set.  I don't think there's any legitimate way in which that 
> > bit can get set.  (Ingo?)
> 
> It's not legitimate (the highest legitimate bit is PREEMPT_ACTIVE, bit 
> 28). Nor can i think of any bug scenario barring outright memory 
> corruption (either hardware or kernel induced) that could cause this. 
> It's quite hard to trigger bit 29 there via any of the scheduling 
> mechanisms: either the preempt count would have to underflow massively 
> /and/ avoid detection during that undflow (sheer impossible) or the 
> HARDIRQ_COUNT would have to overflow to more than 4096 (again near 
> impossible to trigger), and simultaneously the softirq and preempt count 
> would have to overflow by 256 /at once/, or underflow by 1 at once. The 
> likelyhood of that makes the likelyhood of GPL-ed Windows a sure bet in 
> comparison.
> 
> So my guess would still be memory corruption of some sort, or some 
> really weird compiler bug. We just recently mandated REGPARM on i386 for 
> example, it would be interesting to know whether an older (say 2.6.18 or 
> 19) config had CONFIG_REGPARM enabled or not? Regparm can also tax the 
> hardware (the CPU in particular) a bit more.

This is my year-old workstation that I've build from good parts (Asus
A8N-SLI premium, OCZ memory), not overclocked, not overheated (it is
in a Antec P180 case with 12 cm fans -> CPU max is 43'C when not used
for my hour-long simulations).  I will leave it do memtest for a
couple hours.

The compiler is "gcc version 4.1.2 20061028 (prerelease) (Debian
4.1.1-19)" and the .config is attached.

florin

-- 
Bruce Schneier expects the Spanish Inquisition.
      http://geekz.co.uk/schneierfacts/fact/163

View attachment "config-2.6.20-rc2" of type "text/plain" (39880 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)