On Thu, 2011-11-03 at 15:16 -0700, Myklebust, Trond wrote: [..] > No, but we still need to be able to do recovery of rpcsec_gss contexts > once they are broken, and right now we have a major flaw due to the > fact that recovery depends on a lot of small processes and data that > is allowed to be swapped out at the moment when we need them the most > (i.e. in a memory reclaim situation). > > If the server reboots while our client is in the middle of writing > back a file (or several files), then the client needs to recover those > rpcsec_gss contexts that authenticate the processes which own any > dirty pages that remain to be written out. > Key security is an irrelevant concern once your kernel deadlocks in an > OOM state. [..] > > Currently credential caches are stored in files, is there a problem > > with that model ? Do you need access to credential caches from the > > kernel when under memory pressure ? > Yes, there is a major problem with that model, and yes we do > potentially need access to credential caches when in a recovery > situation (which is a situation when we are usually under memory > pressure). This sounds like a catch 22 situation. Even if the keys are pinned in kernel memory you still need the GSSAPI Proxy daemon in order to re-establish the security context, and that process could have been swapped off too. I am not sure I see a way out here. Simo. -- Simo Sorce * Red Hat, Inc * New York -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
