On Tue, 2013-12-31 at 13:01 -0500, J. Bruce Fields wrote: > On Tue, Dec 31, 2013 at 07:33:00AM -0500, Jeff Layton wrote: > > 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). > > Is that the only file under /proc for which that's true? (E.g. the rpc > cache channel files probably do the same, don't they?) I was assuming > tools like sosreport need to work from lists of specific paths. > > > 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. > > That's true. I didn't think the ability to change on the fly was > necessary (but I'll admit it's annoying when debugging at least.) > > > 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. > > The kernel code needs to know which way to handle an incoming packet at > the time it arrives. If it falls back on the legacy upcall that means > failing large init_sec_context calls. So a delayed gss-proxy start (or > a crash and restart) would mean clients erroring out (with fatal errors > I think, not just something that would be retried). Well if gss-proxy is not running it will fail anyway right ? We have 90s before nfsd starts receiving incoming calls at startup right ? Isn't that enough to guarantee whatever the admin configured to start is started ? If gss-proxy is dead for whatever reason a failure will happen anyway now, esp because rpc.gssd will most probably not be running anyway if the admin configured gss-proxy instead ... 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
