NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/43626: directory renaming more than a little racy
>Number: 43626
>Category: kern
>Synopsis: directory renaming more than a little racy
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Jul 16 11:45:00 +0000 2010
>Originator: Antti Kantee
>Release:
>Organization:
>Environment:
>Description:
golem> ./t_renamerace ffs_renamerace_dirs
panic: rename: lost dir entry
Abort (core dumped)
golem> ./t_renamerace ext2fs_renamerace_dirs
panic: rename: linked directory
Abort (core dumped)
golem> ./t_renamerace ext2fs_renamerace_dirs
panic: ext2fs_rename: lost dir entry
Abort (core dumped)
golem> ./t_renamerace lfs_renamerace_dirs
WARNING: the log-structured file system is experimental
WARNING: it may cause system crashes and/or corrupt data
panic: rename: lost dir entry
Abort (core dumped)
golem> ./t_renamerace msdosfs_renamerace_dirs
panic: rename: lost dir entry
Abort (core dumped)
At least LFS is honest.
Additionally, the ffs test can fail with "mkdir: ENOENT/EEXIST"
and the msdos test occasionally just hangs.
I didn't even get around to cross-directory renames or wapbl.
>How-To-Repeat:
run src/tests/fs/vfs/t_renamerace
Note, the results depend at least on the speed of the backend,
i.e. triggering when the image is on tmpfs is a lot more likely
(obviously, since the test can do thousands of times the number
of iterations and spends most of the time in the racy parts
instead of waiting for the disk).
>Fix:
i hope there's a pony
Home |
Main Index |
Thread Index |
Old Index