Created attachment 149353 [details]
Returns the number of file descriptors per process.
What rationale is behind this?
If such syscall is really needed, it may be it will be fast enough to count bits set in the map.
Also what's up with this:
+ p = td->td_proc;
+ td->td_retval = p->p_fd->fd_openfd;
proc lock does not protect file table nor fd_openfd.
So mm@ would not need to silent getdtablecount calls anymore.
So right, FILEDESC_SLOCK should protect f_dp field enough I think ?
Created attachment 149376 [details]
Updated kern code patch
+ p = td->td_proc;
+ fdp = p->p_fd;
+ td->td_retval = fdp->fd_openfd;
proc lock has no useful purpose here. p_fd can change in some cases during fork, but then the process is singlethreaded.
proc lock is a mutex with bound sleep, while filedesc lock has unbound sleep. As such, they cannot be taken in this order anyway.
As a side note, they happen to be taken in the opposide order, so this code gives 2 different opportunities for deadlocks.
The kernel would tell you that if you enabled WITNESS and INVARIANTS.
Lastly, I'm not a fan of counting fds if it can be avoided. As mentioned in my previous comment, the kernel maintains a bitmap of open descriptors. I would suspect counting set bits (= open descriptors) would be fast enough for real life cases.
Fair enough I ll prepare a new version then.
So to be clear, I'm not convinced a syscall like this is needed, but I'm not going to oppose inclusion in the tree, regardless of implementation. This also means I'm not going to commit it.
A commit references this bug:
Date: Sat Nov 14 23:07:39 UTC 2015
New revision: 290835
Implemtn getdtablecount() to count open file descriptors for current process.
Use underlying sysctl implemented by mjg in r290473.
Reviewed by: bapt, mjg
Differential Revision: https://reviews.freebsd.org/D4084
There is a commit referencing this PR, but it's still not closed and has been inactive for some time. Closing the PR as fixed but feel free to re-open it if the issue hasn't been completely resolved.