Opened 12 years ago

Closed 8 years ago

#3685 closed bug (duplicate)

PANIC: vnode already exists

Reported by: rossi Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: #5262 Blocking: #5260
Platform: All


While trying to move files (using Tracker) from an USB HDD to my Haiku partition the system panics in "MoveTask".

See attached "screenshot" for details and back trace.

Revision is 29968.

Attachments (1)

Untitled-1.jpg (479.6 KB ) - added by rossi 12 years ago.

Download all attachments as: .zip

Change History (6)

by rossi, 12 years ago

Attachment: Untitled-1.jpg added

comment:1 by anevilyak, 11 years ago

Blocking: 5260 added

(In #5260) Duplicate of #3685.

comment:2 by anevilyak, 11 years ago

Component: - GeneralSystem/Kernel
Version: R1/pre-alpha1R1/Development

comment:3 by bonefish, 8 years ago

I just ran into a similar panic() that I was able to reproduce and analyze. The cause in my case was a race condition with the VFS's get_vnode() in response to _user_open_dir_entry_ref(). Since get_vnode() first calls create_new_vnode_and_lock() and afterwards the FS's get_vnode() hook, there's a time window where the vnode exists, but the respective node may not exist in the FS. If the node doesn't actually exist and concurrently another thread creates a new file or directory with that node ID, the new_vnode() or publish_vnode() it calls will encounter the existing vnode and fail (the former will panic()).

Not sure what a good solution would be. new_vnode()/publish_vnode() could wait until the vnode becomes unbusy or disappears (a new marker flag might be needed to distinguish the case from others where the node is busy). That might be problematic, however, since the caller may hold a FS specific lock, so that we'd risk a deadlock with the concurrent get_vnode() hook which may also want to acquire that lock.

An IMO cleaner alternative would be to change the interface and semantics of the get_vnode() hook. It would be required to create the vnode (via publish_vnode() or a new interface). We would have to push the burden of dealing with concurrent invocations to the hook, though.

Note that this ticket may actually point to a different problem than the one I've analyzed. In my case vnode->node was expectedly NULL. Here it isn't, though.

comment:4 by umccullough, 8 years ago

It should be noted that #5262 refers to another "vnode already exists" issue as well - with a lot more detail.

comment:5 by bonefish, 8 years ago

Blocked By: 5262 added
Resolution: duplicate
Status: newclosed

Closing this ticket as duplicate of #5262. The situation analyzed by me is tracked in #9839. Whether they are related has not been understood yet.

Note: See TracTickets for help on using tickets.