Hmm... one quick-fix approach would seem to be to pass LOCK_RECURSIVE to
mutex_init.
On that note, it's not clear to me yet why we're even using mutexes
here. Isn't there only a single lockd process? And in that case, all
these mutexes are private, no? Or is it possible to start two lockd's
for higher performance (not something I've ever done).
Alternatively, create a new function:
/*
* Check to see if it's time to sweep the garbage out of the hosts structures.
*/
static void
nlm_gc_hosts_if_needed(void)
if (time_after_eq(jiffies, next_gc))
nlm_gc_hosts();
}
...remove the corresponding code from nlm_lookup_host (...), and invoke
nlm_gc_hosts_if_needed from somewhere outside the file-specific mutex
code. Maybe in the lockd main loop, after each call to svc_process
(...).
I think I'll try that with my code. I'm just a bit worried about
performance impact of making all file mutexes recursive. Surely a
recursive mutex has to be a bit of a hit compared to the vanilla
version?
--
NFS server: lockd: server not responding
https://bugs.launchpad.net/bugs/181996
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
