linux-kernel - Re: [PATCH 18/38] C/R: core stuff

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: <20090526131644.GA20920@hallyn.com>
Date:	Tue, 26 May 2009 08:16:44 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	akpm@...ux-foundation.org, xemul@...allels.com,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 18/38] C/R: core stuff

Quoting Alexey Dobriyan (adobriyan@...il.com):
> Introduction
> ------------
> Checkpoint/restart (C/R from now) allows to dump group of processes to disk
> for various reasons like saving process state in case of box failure or
> restoration of group of processes on another or same machine later.
> 
> Unlike, let's say, hypervisor C/R style which only needs to freeze guest kernel
> and dump more or less raw pages, proposed C/R doesn't require hypervisor.
> For that C/R code needs to know about all little and big intimate kernel details.
> 
> The good thing is that not all details needs to be serialized and saved
> like, say, readahead state. The bad things is still quite a few things
> need to be.

Hi Alexey,

the last time you posted this, I went through and tried to discern the
meaningful differences between yours and Oren's patchsets.  Then I sent some
patches to Oren to make his set configurable to act more like yours.  And Oren
took them!  But now you resend this patchset with no real changelog, no
acknowledgment that Oren's set even exists - or is much farther along and
pretty widely reviewed and tested (which is only because he started earlier
and, when we asked for your counterpatches at an earlier stage, you would never
reply) - or, most importantly, what it is that you think your patchset does
that his does not and cannot.  *Why* are you spending your time on this instead
of helping with Oren's set?  The code really isn't all that different...  Maybe
you just think that two independently written patchsets will expose more
gotchas that we'll need to catch, so you're continuing on this effort under the
expectation that eventualy we'll merge the two sets?

Honestly, I have great respect for your coding abilities.  And if 'voices
from on high' tell us to base upon your code, I'd be fine with that, I
have no real problems with what I see on yet another cursory look.  But
given the amount of collective time that's been spent developing, reviewing,
and testing Oren's set, it wouldn't make any sense to just jump.  So
I'd still just like to know how you see this proceeding.

thanks,
-serge
--
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/