Date: Thu, 11 Apr 2019 01:24:03 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Mateusz Guzik <mjg@FreeBSD.org> Cc: "kib@freebsd.org" <kib@FreeBSD.org>, "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Do the pidhashtbl_locks added by r340742 need to be sx locks? Message-ID: <QB1PR01MB35371458E0E88BA357633D50DD2F0@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
Hi,
I finally got around to looking at what effect replacing pfind_locked() wit=
h
pfind() has for the NFSv4 client and it is broken.
The problem is that the NFS code needs to call some variant of "pfind()" wh=
ile
holding a mutex lock. The current _pfind() code uses the pidhashtbl_locks,
which are "sx" locks.
There are a few ways to fix this:
1 - Create a custom version of _pfind() for the NFS client with the sx_X() =
calls
removed, plus replace the locking of allproc_lock with locking of all=
the
pidhashtbl_locks, so that the "sx" locks are acquired before the mute=
x.
--> Not very efficient, but since it is only done once/sec, I can liv=
e with it.
2 - Similar to the above, but still lock the allproc_lock and use a loop of
FOREACH_PROC_IN_SYSTEM(p) instead of a hash list for the pid in the
custom pfind(). (I don't know if this would be preferable to locking a=
ll
the pidhashtbl_locks for other users of pfind()?)
3 - Convert the pidhashtbl_locks to mutexes. Then the NFS client doesn't ne=
ed
to acquire any proc related locks and it just works.
I can't see anywhere that "sleeps" while holding the pidhashtbl_locks,=
so I
think they can be converted, although I haven't tried it yet?
>From my perspective, #3 seems the better solution.
What do others think?
rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB35371458E0E88BA357633D50DD2F0>