linux-kernel - Re: [PATCH 05/10] Core checkpoint/restart support code

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Apr 2011 16:53:44 -0500
From:	"Serge E. Hallyn" <serge.hallyn@...ntu.com>
To:	Nathan Lynch <ntl@...ox.com>
Cc:	"Serge E. Hallyn" <serge.hallyn@...onical.com>,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [PATCH 05/10] Core checkpoint/restart support code

Quoting Nathan Lynch (ntl@...ox.com):
> >   If it can gain traction
> > better than linux-cr, that'd be one thing.  But given the amount of
> > review and testing the other tree has gotten
> 
> How much traction do you think linux-cr has?  It doesn't seem any closer
> to mainline than it was a year ago, and it barely has any users.  I
> don't think posting this little proof-of-concept patch set is disrupting
> linux-cr's progress toward mainline.

No, I agree with you there.  I appreciate your attempt, and it would have
been great if it had worked.  My comments are only about going forward
from today onward.  And, going forward, I don't believe that this API
simplification (and regression in functionality) is going to pay off
the way you'd hoped.

> > I'd really prefer that everyone was using the same tree, and sending
> > any and all patches which they need, no matter how ugly they fear
> > they are, upstream.  To that end, I think it would be appropriate
> > for you or Dan to get write access to Oren's tree or to move to a
> > newly cloned copy of his tree to which one of you has acces.
> 
> Oren and I disagree on some fundamental aspects of how kernel c/r should
> be implemented (hence this patch set), so I'm not sure how this would
> work.

Ok, not you then :)

I'm willing to do it, but since I won't be able to spend full time
reviewing it, I'd have to set some ground-rules, like:  I"ll pull in
any patch as soon as it has an ack from (Oren, Dan Smith, Matt
Helsley) which is not also from the submitter.  Any regression in
automated tests cause the patch which caused it to get kicked out.

If you want to discuss the technical advantages of not allowing a task
to call checkpoint on another task, let's start a new thread to do that.
So far, I'm against it.

thanks,
-serge

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