Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Oct 2017 00:08:15 +0000
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Mateusz Guzik <mjguzik@gmail.com>, Ian Lepore <ian@freebsd.org>
Cc:        "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>, "fabian.freyer@physik.tu-berlin.de" <fabian.freyer@physik.tu-berlin.de>
Subject:   Re: pfind_locked(pid) fails when in a jail?
Message-ID:  <YTOPR0101MB21720E11F5490FC3CE568FF6DD4F0@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <20171016233912.7n6rosak5a5tzcbz@mguzik>
References:  <YTOPR0101MB2172A4421C7B012A503230D5DD4F0@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM> <CAGudoHEvDk0mKCmK59sPM7j-Mt279rLZwTwVazX5ktX=7wD-9Q@mail.gmail.com> <1508195986.74236.6.camel@freebsd.org>, <20171016233912.7n6rosak5a5tzcbz@mguzik>

next in thread | previous in thread | raw e-mail | index | archive | help
[stuff snipped]
> > >
> > pfind* does not do any filtering.
> >
Hmm, well I have no idea why the jailed mounts get looping in here then.

> > 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 sav=
ing
> > the pid.
> >
Long long ago (about 2002) this code was written for OpenBSD2.6. I added
a call from the kernel exit() code to do this. When I ported it to FreeBSD
around 2005, I didn't find any way for a process exit notification to be do=
ne,
so I created the first version of this code. (This way of doing it was firs=
t
coded for Mac OS X 10.3, if I recall correctly.)

Since it does check that the time of process creation is the same, it doesn=
't
seem likely that it would find a different process (ie. two processes with =
the
same pid that were created at the same time within the clock resolution of
that creation time seems highly unlikely in practice?).

> > There is no usable process exit notification right now, but it can be a=
dded
> > if necessary.
> >
If there was a way for the NFS client to register to get a notification tha=
t a
given process is terminating (exit'ng), that could certainly be used instea=
d
of this code.

I wouldn't want a call for every exit(), but only the ones that have NFSv4 =
opens.

>>
>> Does that mean there is something wrong with the existing eventhandler
>> notifications related to proc fork/exec/exit?
>>
>
>I already noted in the other mail that the current mechanism has
>avoidable global locking, lists traversals etc. But even with these
>issues fixed it calls everything for everyone.
>
>What's needed is a mechanism to register per-process callbacks. Details
>can be flamed over (e.g. should it require allocating a buffer per
>process or perhaps just one and then point to it from a resizable
>per-proc table when registered), but calling something which has nothing
>to do in almost all cases and from in a super inefficient way at that is
>definitely something we need to start cleaning up.
Yes, I would agree, although it doesn't explain what this CPU hog case is
caused by.

Thanks for the comments and if you create/commit the above, let me know
and I'll change the NFS client code to use it (if your patch doesn't do tha=
t).

rick




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB21720E11F5490FC3CE568FF6DD4F0>