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