11:27 p.m.
Thanks for raising it on Ganesha list.
Just want to add, once fds are depleted, they are not getting cleaned up
even after hours. I needed to restart Ganesha process to recover from this
state.
I am not sure if idle cleanup code is able to get rid of extra ref and
release xprt.
I tried with this fix in cleanup code its working for me.
https://paste.fedoraproject.org/paste/lapz1NrOlBxS342S4Q79aw
Regards,
Gaurav
On Sun, Dec 2, 2018 at 4:49 AM William Allen Simpson <
william.allen.simpson(a)gmail.com> wrote:
This was reported on ntirpc at Github. After DanG's fix for
transport reference counting, Gaurav Gangalwar wrote that s/he
can deplete the available fds with:
for i in {1..1000}; do echo $i; mount -t nfs -o vers=3,tcp :/export
/mnt; umount /mnt; done
There is a configurable parameter limiting the number of
concurrent fds. They are cleaned up after a fairly long
inactivity timeout. So an adversary (or runaway client) can
quickly deplete the fds, preventing valid clients from mounting.
The most obvious patch would be for umount to add the same
SVC_DESTROY line that DanG (and previously me) had added for the
TCP well known ports in dispatch.
But that would allow runaway clients to flood the server.
Preventing that seems to be the (undocumented) purpose of the
configurable parameter.
The parameter and cleanup code are relatively old, and added to
ntirpc circa 2013. Was it a bad idea?
Which security issue is more important?
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org