I'm also seeing locking problems, although not resulting in deadlock, so not the same problem. I've tested with FUSE 1.2 + hide_node changes backported, and with FUSE CVS.
In my case, I believe the problem may be due to race conditions for FUSE's internal node state. The result is either fuse aborting from get_node, or else passing a request through to the user filesystem with an old name after renaming a file.
Some paths (I'm looking at the rename path and open paths) go through multiple lock / unlock phases, but there doesn't seem to be anything preventing the internal node state from being changed between one set of locks and another.
Note that I didn't see the locking problems at first. It was running fine on my system, but another user of my filesystem reported the problems to me. It may be that my system is faster then his, or due to differences in threading implementation, and so the window of opportunity for a race condition was smaller. But when I run my filesystem under valgrind, which slows down all operations by quite a bit, then I also see the problems.
I've been testing per-node locks across multi-step operations, but still testing. I just wanted to report that I've also been seeing thread locking related issues.
On Wed, 2004-06-30 at 10:42, Miklos Szeredi wrote:
> I'm still seeing cases where I have up to 8 threads all waiting for
> locks, no CPU is being consumed.
OK. At least this shouldn't be a spinlock problem like the last one,
because that would show a 100% CPU load.