> there is a concurrency problem that is being avoided.
correct, there are 3 items that involved into the problem:
1. IOCTLs that do
3. ZFS-Recv: **dmu_recv_end()**->....->**dsl_dataset_handoff_check()**->check
> For the second issue, I'd need more information about the race condition to
> speculate on the proper fix, but I again suspect retrying is not the best
> solution. Is that one related to https://www.illumos.org/issues/3875?
correct, 3875 is related.
There is a race between **zfs_umount()** and **getzfsvfs()** and ignore of the
result of **zfs_suspend_fs()**
1. **zfs_umount()** successfully checks that there are no holders and umount
can be finished, after that it does **dmu_objset_set_user(os, NULL)** and
2. At the same time **getzfsvfs()** can be called by ZFS-Recv. It does
**dmu_objset_get_user()**, that requires lock of **os->os_user_ptr_lock**.
**dmu_objset_set_user()** also requires the lock.
So if step2 is the first on the lock, then we will see a panic that is caused
**VERIFY3P(ds->ds_owner, ==, owner)** inside of
**dsl_dataset_handoff_check()**. To avoid the panic need to handle result of
**zfs_suspend_fs()**, because it will fail for umounted FS.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Delivery options: https://openzfs.topicbox.com/groups