[haiku-bugs] Re: [Haiku] #11718: userlandfs -> Failed to acquire spinlock for a long time (last caller: 0x0, value: deadbeef)

From: "bonefish" <trac@xxxxxxxxxxxx>
Date: Tue, 10 Mar 2015 10:44:33 -0000

#11718: userlandfs -> Failed to acquire spinlock for a long time (last caller: 
0x0,
value: deadbeef)
---------------------------------------+----------------------------
   Reporter:  ttcoder                  |      Owner:  bonefish
       Type:  bug                      |     Status:  new
   Priority:  high                     |  Milestone:  R1/beta1
  Component:  File Systems/UserlandFS  |    Version:  R1/Development
 Resolution:                           |   Keywords:
 Blocked By:                           |   Blocking:
Has a Patch:  0                        |   Platform:  All
---------------------------------------+----------------------------

Comment (by bonefish):

 A quick info on the involved userlandfs classes:
  * `Volume`: Each mounted instance is associated with an instance of this
 class. Among other things it does a bit of book keeping so that a buggy
 client FS can't cause vnode or file descriptor reference imbalances and
 also has fallback implementations for vital FS hooks, so that the FS is
 well-behaved and can still be unmounted, even if the connection to the
 userlandfs server is lost (e.g. due to crashing or being killed).
  * `FileSystem`: Each client file system (type) that has a mounted volume
 is associated with an instance of this class. It manages the connection to
 the userlandfs server instance for that file system. `FileSystem` objects
 are reference counted. When the last volume of a client file system has
 been unmounted, the object is destroyed.
  * `RequestPortPool`: Manages a pool of (regular) ports that the
 userlandfs kernel module uses for communication with the userlandfs server
 instance. `FileSystem` has an aggregate `RequestPortPool`.

 According to the stack strace the 0xdeadbeef is encountered when locking
 the `FileSystem`'s `RequestPortPool`. That suggests that the `FileSystem`
 has been deleted already. Given that the `FileSystem` could be accessed
 via the `Volume` in the first place, the `Volume` hadn't been deleted at
 that point yet. Since a mutex is involved, it is possible that the
 `Volume` already has been deleted at the time of the panic, though.

 So, the situation suggests either a reference counting/race condition
 issue in userlandfs or the VFS is calling the `unmount()` hook while the
 `read_fs_info()` hook is still being executed.

 ATM I can't think of anything that the client FS (cddafs) can do to cause
 either problem. So I guess it's a genuine userlandfs or VFS bug.

--
Ticket URL: <https://dev.haiku-os.org/ticket/11718#comment:9>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.

[haiku-bugs] Re: [Haiku] #11718: userlandfs -> Failed to acquire spinlock for a long time (last caller: 0x0, value: deadbeef)

Other related posts: