linux-kernel - Re: [TuxOnIce-devel] Nigel's current for-rafael queue

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: <201009282145.46948.Martin@lichtvoll.de>
Date:	Tue, 28 Sep 2010 21:45:37 +0200
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	tuxonice-devel@...ts.tuxonice.net
Cc:	Nigel Cunningham <nigel@...onice.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"TuxOnIce-devel" <tuxonice-devel@...onice.net>
Subject: Re: [TuxOnIce-devel] Nigel's current for-rafael queue

Am Samstag 25 September 2010 schrieb Nigel Cunningham:
> Hi Rafael.

Hi Nigel,

> Please find attached a slightly updated version of the patchset I sent
> a few months ago. The main change is that I've prepended and additional
> patch which lets the user see the speed at which the image is being
> read and written. This is accomplished by recording the MB/s in a
> single byte in the image header, and using a couple of __nosavedata
> variables to get the data back through the atomic restore. I realise
> the char limits us to 255MB/s at the moment. In future patches, I
> intend to address this by storing the data in a 'proper' image header
> (it's a real problem - TuxOnIce reads and writes on the same set up at
> speeds around 250MB/s).
> 
> Results on my Dell XPS M1530, which has an SSD hard drive are:

I found one issue with this patchset or more precise I think with the 
state of in-kernel-suspend before:

I accidentally booted a kernel without your patches and it didn't seem to 
stop on the hibernation image from the kernel with your patches. Well I 
let my laptop unattended for a little while, so when there has been a 
(short) timeout, I might have missed that message.

I lost a hibernation image this way which caused successful journal replay 
on my Ext4 filesystems. 

Does a kernel without your patches offer to reboot into the correct kernel, 
then it finds a hibernation image from a kernel with your patches?

If not, I think for the future it should give a warning with a quite high 
timeout, and offer to reboot into the right kernel.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

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