Re: should we change how the kernel detects whether gssproxy is running?

[Simo Sorce <simo@redhat.com>]

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