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

From: "anevilyak" <trac@xxxxxxxxxxxx>
Date: Tue, 10 Mar 2015 02:06:26 -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 anevilyak):

 Replying to [comment:6 ttcoder]:
 > Is it a realistic prospect to try and compile a custom build of Tracker
 that does not call TrashWatcher ..etc on userlandfs devices ? We've been
 thinking of doing that as a workaround if all else fails.. So I thought
 I'd humbly ask for advice from the savvy ones here, before I embark on
 that kind of hacking, in case the more experienced devs tell me it's a low
 return on invested time tactic...

 The problem is, Tracker is simply a victim of a deeper underlying problem
 here ; at the end of the day, since you're making use of cdda via various
 tools even without Tracker being involved, somebody is going to eventually
 wind up triggering this issue. Given that it happens in both the case of
 cdda directly in the kernel, as well as when cdda is mounted via
 userlandfs, this somewhat narrows down the possible candidates, but only
 to an extent.

 The 0xdeadbeef in the panics here implies that someone is freeing kernel
 memory that's still in use/referenced somewhere. The main difference when
 cdda is invoked via userlandfs rather than via the kernel directly is that
 most of the meat of cdda runs in userland. However, userlandfs must still
 forward all of the kernel/VFS interactions back and forth (i.e. when the
 ripper requests to open a file, read a block, etc.). As such, there are
 two likely possibilities here. Either 1) cdda isn't doing some bookkeeping
 correctly when it interacts with the VFS, such as calling put_vnode() in a
 case where it shouldn't, or 2) the way cdda is interacting with the VFS is
 triggering a corner case/bug in the VFS itself. An outside edge case is
 that it could also be an issue with the ATAPI code, but that would suggest
 a similar problem could be triggered with data CDs, which to my knowledge
 has not been reported to be the case, so that one seems less likely.

 The first case would probably be the easier one to try to
 investigate/eliminate first since that would mainly require review of the
 cdda code on its own, whereas the second would obviously require reviewing
 the VFS and related code, which is there is considerably more of, and is
 also significantly more complex, so I'd suggest the former route first.

--
Ticket URL: <https://dev.haiku-os.org/ticket/11718#comment:7>
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: