linux-kernel - Re: 2.6.17-rt8 crash amd64

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]

Message-ID: <20060802173553.GA29327@gnuppy.monkey.org>
Date:	Wed, 2 Aug 2006 10:35:53 -0700
From:	Bill Huey (hui) <billh@...ppy.monkey.org>
To:	Daniel Walker <dwalker@...sta.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org,
	"Bill Huey (hui)" <billh@...ppy.monkey.org>
Subject: Re: 2.6.17-rt8 crash amd64

On Wed, Aug 02, 2006 at 10:16:44AM -0700, Daniel Walker wrote:
> On Wed, 2006-08-02 at 00:13 -0700, Bill Huey wrote:
> 
> >   [ 3254.657547] BUG: scheduling while atomic: mv/0x00000001/5222
> >   [ 3254.663380]
> >   [ 3254.663381] Call Trace:
> >   [ 3254.667255]        <ffffffff8025ef25>{__schedule+155}
> >   [ 3254.672491]
> >   <ffffffff802616cb>{_raw_spin_unlock_irqrestore+81}
> 
> >   [ 3254.836278]        <ffffffff8025df02>{ia32_sysret+0}
> >   [ 3254.841606] ---------------------------
> >   [ 3254.845554] | preempt count: 00000001 ]
> >   [ 3254.849503] | 1-level deep critical section nesting:
> >   [ 3254.854614] ----------------------------------------
> >   [ 3254.859725] .. [<ffffffff8025ef3d>] .... __schedule+0xb3/0xb2a
> >   [ 3254.865743] .....[<ffffffff8025fbab>] ..   ( <=
> >   preempt_schedule+0x55/0x8f)
> 
> 
> _raw_spin_unlock_irqrestore() calls preempt_schedule() which calls
> __schedule() , maybe (should be impossible though)? 
> 
> Are you using a 32-bit userspace and a 64-bit kernel ?

Yes, but this happens with 64 bit apps as well. I'm going to take a
deeper look at it today. My current track is to look at processes
reaping. That seems to be a common attribute in all of those stack
traces. I thought there was more debug instrumentation that dealt
with preempt_count tracking before ?

bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/