I'm a bit concerned with how /proc/net/rpc/use-gss-proxy works... For one thing, when the kernel first boots any read against that file hangs. That's going to be extremely problematic for certain tools that scrape info out of /proc for troubleshooting purposes (e.g. Red Hat's sosreport tool). Also, it seems like if gssproxy suddenly dies, then this switch stays stuck in its position. There is no way switch back after enabling gssproxy. All of that seems unnecessarily complicated. Is there some rationale for it that I'm missing? Would it instead make more sense to instead just have gssproxy hold a file open under /proc? If the file is being held open, then send upcalls to gssproxy. If not then use the legacy code. That way the upcalls would truly be conditional on whether gssproxy is running... -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
