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
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.
run a puffs file server which crashes in rename.  get lucky with
take reference to mp around rename

Home | Main Index | Thread Index | Old Index