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: Fri, 10 Oct 2008 10:46:14 +0200 From: Ingo Molnar <mingo@...e.hu> To: Dave Hansen <dave@...ux.vnet.ibm.com> Cc: "Serge E. Hallyn" <serue@...ibm.com>, containers@...ts.linux-foundation.org, arnd@...db.de, linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>, Arjan van de Ven <arjan@...radead.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl> Subject: Re: [RFC][PATCH 2/2] first callers of process_deny_checkpoint() * Dave Hansen <dave@...ux.vnet.ibm.com> wrote: > On Thu, 2008-10-09 at 14:43 -0500, Serge E. Hallyn wrote: > > Hmm, I don't know too much about aio, but is it possible to succeed with > > io_getevents if we didn't first do a submit? It looks like the contexts > > are looked up out of current->mm, so I don't think we need this call > > here. > > > > Otherwise, this is neat. > > Good question. I know nothing, either. :) > > My thought was that any process *trying* to do aio stuff of any kind > is going to be really confused if it gets checkpointed. Or, it might > try to submit an aio right after it checks the list of them. I > thought it best to be cautious and say, if you screw with aio, no > checkpointing for you! as long as there's total transparency and the transition from CR-capable to CR-disabled state is absolutely safe and race-free, that should be fine. I expect users to quickly cause enough pressure to reduce the NOCR areas of the kernel significantly ;-) In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate? That would be way cool for users and for testing: we could do transparent kernel upgrades/downgrades via this form of hibernation, between CR-compatible kernels (!). distros could mark certain kernels as 'safe fallback' kernels, and if say a WARN_ON() or app breakage hits that is suspected to be kernel related, the user could hit a 'switch back to safe kernel' button - which would switch back _without losing any app state_. People could even try new versions of the kernel which would just fall back to the known-workin safe kernel if the bootup fails for example. Pie in the sky for sure, but way cool: it could propel Linux kernel testing to completely new areas - new kernels could be tried non-intrusively. (as long as a new kernel does not corrupt the CR data structures - so some good consistency and redundancy checking would be nice in the format!) Ingo -- 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