Project

General

Profile

Actions

Bug #13243

open

deadlock on ZFS during concurrent rename and mkdir

Added by Mateusz Guzik over 1 year ago. Updated 6 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

wget https://www.netbsd.org/~riastradh/tmp/dirconc.c
cc -pthread -o dirconc dirconc.c
mkdir foo
dirconc ~/foo > /dev/null

Hangs a 2 core vm for me.

The system is

SunOS omniosce 5.11 omnios-r151034-0d278a0cc5 i86pc i386 i86pc
so not the freshest possible, but I can't update right now. However, I do suspect it is readily reproducible by other people.

Does not run into anything on tmpfs presumably thanks to mount point-wide rename lock employed there.

As a data point, it does NOT reproduce on FreeBSD HEAD (running OpenZFS). I have not tried older version.


Related issues

Is duplicate of illumos gate - Bug #7193: deadlock between zfs_rename and zfs_rmdirNew2016-07-18

Actions
Actions #1

Updated by Joshua M. Clulow over 1 year ago

  • Project changed from site to illumos gate
Actions #2

Updated by Dan McDonald 6 months ago

I've tried this on a non-debug OmniOS bloody (omnios-master-583b18de89) in /tmp (but without redirecting stdout to /dev/null) and in my ZFS home directory (with redirecting stdout to /dev/null) which DOES seem to deadlock/hang-on-cv_wait. I.e. an unkillable process.

A coredump induced by `reboot -d` from this is available here: https://kebe.com/~danmcd/webrevs/13243/vmdump.1

I re-reproduced it on a DEBUG kernel and it misbehaved the same way. Kernel dump is https://kebe.com/~danmcd/webrevs/13243/vmdump.2

I noticed the bug's filer has made changes in OpenZFS particular to the FreeBSD vnop code. Our fix will likely be somewhere similar.

Actions #3

Updated by Jason King 6 months ago

  • Is duplicate of Bug #7193: deadlock between zfs_rename and zfs_rmdir added
Actions

Also available in: Atom PDF