On Tue, 9 Dec 2014 20:55:30 +0100 David Härdeman <david@xxxxxxxxxxx> wrote: > On Tue, Dec 09, 2014 at 09:58:13AM -0500, Jeff Layton wrote: > >> On 2014-12-09 14:09, Jeff Layton wrote: > >>> One thing that _would_ be nice while you're in here though would be to > >>> help parallelize more of process_krb5_upcall. Currently it forks before > >>> changing its identity and then the parent waits on that to exit which > >>> keeps everything serialized. > > > >Ahh, now I remember. It's not the closing of the fds that's the > >problem, but you do need to have some way to reap the exit status from > >the processes that are being forked off (so you don't end up with > >zombies). > > That's probably something that's been looked into before with libevent > (says he, without doing any research). > I imagine so. > Another question that comes to mind...if we're anyway forking a child > per gssd request...how far has the idea of changing rpc.gssd over to a > /sbin/request-key helper been considered? I've seen some traces of > historical discussions via google but nothing concrete so far... > (cc'ing David in case I'm wrong on this point) Yes. The problem with keyrings is that while the in-kernel parts are namespace-aware, the upcalls are not. /sbin/request-key is spawned by a kernel thread that lives in the init namespaces. Any solution that involves a usermodehelper upcall will need to figure out how to handle containerized clients. Another idea might be to scrap rpc.gssd altogether and communicate with gssproxy directly (but that too involves running a daemon, of course). -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- 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
