From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mbroz@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
	by mail.saout.de (Postfix) with ESMTP
	for <dm-crypt@saout.de>; Wed,  7 Jul 2010 22:44:32 +0200 (CEST)
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o67KiVDE005029
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <dm-crypt@saout.de>; Wed, 7 Jul 2010 16:44:31 -0400
Received: from [10.36.7.249] (vpn1-7-249.ams2.redhat.com [10.36.7.249])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id o67KiUZu026758
	for <dm-crypt@saout.de>; Wed, 7 Jul 2010 16:44:31 -0400
Message-ID: <4C34E72E.8070809@redhat.com>
Date: Wed, 07 Jul 2010 22:44:30 +0200
From: Milan Broz <mbroz@redhat.com>
MIME-Version: 1.0
References: <1278523178.9943.5.camel@Koma-Station.localdomain>	<20100707173658.GA20180@tansi.org>	<1278524944.9943.9.camel@Koma-Station.localdomain>
	<20100707201955.GA22353@tansi.org>
In-Reply-To: <20100707201955.GA22353@tansi.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] crypsetup segfaulting during luksFormat
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

On 07/07/2010 10:19 PM, Arno Wagner wrote:
> On Wed, Jul 07, 2010 at 07:49:04PM +0200, Sven Eschenberg wrote:
>> Hummm,
>>
>> should I consider this geek humor or are you serious, the CPU is rather
>> slow (imho)?
> 
> Par humor, part serious. But if the CPU is rather slow, then
> this is somethin else, I guess.

Don't worry, it was optimized such way that even on slow machines
it crashes quickly :-)

>> Well at least we know the crash happens in sigvtalarm, which I assume is
>> a signal handler of some sort within cryptsetup.

The timer is there intentionally to calculate PBKDF2 iterations per second,
after one second is loop stopped. There is safe limit (IIRC 1000
iterations) - so even on slow CPU it returns safe value.
(iteration count is unsigned 64bit number, it should not overflow,
ale least not in this century :-)

Anyway, I need debug log and info I requested to analyse it.

Milan