NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/41051: do_sys_rename mp resource race
>Number: 41051
>Category: kern
>Synopsis: do_sys_rename mp resource race
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Mar 21 07:25:00 +0000 2009
>Originator: Antti Kantee
>Release:
>Organization:
>Environment:
>Description:
As reported by Uebayasi-san, a MNT_FORCE unmount during rename may
cause the renamelock to be destroyed while it is still locked.
db{1}> bt
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x249
lockdebug_abort() at netbsd:lockdebug_abort+0x42
mutex_destroy() at netbsd:mutex_destroy+0x38
vfs_destroy() at netbsd:vfs_destroy+0x58
puffs_msgif_close() at netbsd:puffs_msgif_close+0x67
putter_fop_close() at netbsd:putter_fop_close+0x63
closef() at netbsd:closef+0x70
fd_close() at netbsd:fd_close+0x137
fd_free() at netbsd:fd_free+0xb7
exit1() at netbsd:exit1+0x12f
sigexit() at netbsd:sigexit+0x1ab
postsig() at netbsd:postsig+0x13b
lwp_userret() at netbsd:lwp_userret+0x177
syscall() at netbsd:syscall+0x17c
> Hmm, can you verify that vfs_destroy+0x58 is the line where it destroys
> mnt_renamelock?
Yes, it is.
>How-To-Repeat:
run a puffs file server which crashes in rename. get lucky with
timing.
>Fix:
take reference to mp around rename
Home |
Main Index |
Thread Index |
Old Index