Re: pfind_locked(pid) fails when in a jail?

On Tue, 2017-10-17 at 00:38 +0200, Mateusz Guzik wrote:
> On Tue, Oct 17, 2017 at 12:24 AM, Rick Macklem <rmacklem_at_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_at_
> > 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
> calls
> I grepped in nfscl_procdoesntexist are highly suspicious - there is no
> guarantee
> 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?

-- Ian