linux-kernel - Re: 2.6.25-mm1: not looking good

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: <48089BCA.1090704@windriver.com>
Date:	Fri, 18 Apr 2008 08:02:02 -0500
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Vegard Nossum <vegard.nossum@...il.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>, tglx@...utronix.de,
	penberg@...helsinki.fi, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	jmorris@...ei.org, sds@...ho.nsa.gov
Subject: Re: 2.6.25-mm1: not looking good

Vegard Nossum wrote:
> On Fri, Apr 18, 2008 at 2:34 PM, Ingo Molnar <mingo@...e.hu> wrote:
>   
>>  * Vegard Nossum <vegard.nossum@...il.com> wrote:
>>
>>  > With the patch below, it seems 100% reproducible to me (7 out of 7
>>  > bootups hung).
>>  >
>>  > The number of loops it could do before hanging were, in order: 697,
>>  > 898, 237, 55, 45, 92, 59
>>
>>  cool! Jason: i think that particular self-test should be repeated 1000
>>  times before reporting success ;-)
>>     
>
> BTW, I just tested a 32-bit config and it hung after 55 iterations as well.
>
> Vegard
>
>
>   
I assume this was SMP?

While I had not tried it yet, my guess would have been this did not
happen on a UP kernel.  If it does occur on a UP kernel it means the
problem is squarely between the task scheduling after the exception is
handled and the kgdb state logic for re-entering the debug state after a
single step exception occurs.

It seems reasonable to go for 1000 iterations of this particular test to
declare success as pointed out by Ingo.  Previous versions of kgdb
handled some of the irq + single step + cpu sync slightly differently
and it is entirely possible there is a regression there.

Jason.
--
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/