On Wed, 1 Jan 2014 09:56:20 +1100 NeilBrown <neilb@xxxxxxx> wrote: > On Tue, 31 Dec 2013 13:01:23 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> > 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. > > The rpc cache channel files do not block on reads, so 'cat' works well on > them. > A process (like mountd) that wasn't to see new additions will use select (or > poll) for an 'exception' condition, and then read. > > I think that it is best of all files in /proc (or /sys) would support 'cat'. > If I "tar" up "/proc" on my notebook it doesn't block ... though it does take > quite a while on /proc/kcore :-) > I think we have to deal with the possibility that something will eventually get stuck reading this file. I can understand why you might make the kernel hang for a little while waiting for gssproxy to start up or something. What's not clear to me is why you'd make userland reads vs. this particular proc file hang. What problem is fixed by making this hang? -- Jeff Layton <jlayton@xxxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
