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
| ||
|
Date: Tue, 21 Apr 2009 19:16:05 -0500 From: Nathan Lynch <ntl@...ox.com> To: Oren Laadan <orenl@...columbia.edu> Cc: Alexey Dobriyan <adobriyan@...il.com>, Linux-Kernel <linux-kernel@...r.kernel.org>, Dave Hansen <dave@...ux.vnet.ibm.com>, containers@...ts.osdl.org, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Ingo Molnar <mingo@...e.hu> Subject: Re: C/R without "leaks" Oren Laadan <orenl@...columbia.edu> writes: > Alexey Dobriyan wrote: >>> Again, so to checkpoint one task in the topmost pid-ns you need to >>> checkpoint (if at all possible) the entire system ?! >> >> One more argument to not allow "leaks" and checkpoint whole container, >> no ifs, buts and woulditbenices. >> >> Just to clarify, C/R with "leak" is for example when process has separate >> pidns, but shares, for example, netns with other process not involved in >> checkpoint. >> >> If you allow this, you lose one important property of checkpoint part, >> namely, almost everything is frozen. Losing this property means suddenly >> much more stuff is alive during dump and you has to account to more stuff >> when checkpointing. You effectively checkpointing on live data structures >> and there is no guarantee you'll get it right. > > Alexey, we're entirely on par about this: everyone agrees that if you > want the maximal guarantee (if one exists) you must checkpoint entire > container and have no leaks. > > The point I'm stressing is that there are other use cases, and other > users, that can do great things even without full container. And my > goal is to provide them this capability. As it seems that Alexey's goal is more or less a subset of yours, would it make sense in the near term to concentrate on getting an implementation upstream that satisfies that subset (i.e. checkpoint on a container basis only)? And then support for checkpointing arbitrary processes could be added later, if it proves feasible? -- 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/
Powered by blists - more mailing lists