On Tue, 2017-10-17 at 00:38 +0200, Mateusz Guzik wrote:
> On Tue, Oct 17, 2017 at 12:24 AM, Rick Macklem <rmack...@uoguelph.ca> wrote:
> > Hi,
> > A problem w.r.t. the NFSv4 client's renew thread (nfscl) running up a lot
> > of CPU
> > when the NFSv4 mount is in a jail has been reported to the freebsd-stable@
> > mailing list.
> > I know nothing about jails, but when looking at the code, the most obvious
> > cause of this would be "pfind_locked(pid)" failing to find a process.
> > - Will a jail affect how pfind_locked() behaves?
> > - If the answer is "yes", then I need to know how to either...
> > 1 - Make pfind_locked() work the same as when no jail exists.
> > OR
> > 2 - A way for the Renew thread can determine that a jail will affect
> > pfind_locked()
> > behaviour, so it can avoid this problem.
> > #1 is preferred, since #2 may not be 100% correct, although #2 would allow
> > the
> > code to behave well for most cases. (The exception is a case where a file
> > remains
> > open for a long period of time, with different processes doing byte range
> > locks on
> > the file.)
> pfind* does not do any filtering.
> The real question though is why are you calling it in the first place. The
> I grepped in nfscl_procdoesntexist are highly suspicious - there is no
> the process you found here is the same you had at the time you were saving
> the pid.
> There is no usable process exit notification right now, but it can be added
> if necessary.
Does that mean there is something wrong with the existing eventhandler
notifications related to proc fork/exec/exit?
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"