> there is a concurrency problem that is being avoided.
correct, there are 3 items that involved into the problem:
1. IOCTLs that do 
**zfsvfs_hold()**->**zfsvfs_create()**->**dmu_objset_own()**->long-hold
2. **zfs_domount()**->**zfsvfs_create()**->**dmu_objset_own()**->long-hold
3. ZFS-Recv: **dmu_recv_end()**->....->**dsl_dataset_handoff_check()**->check 
long-holds

> 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 
**dmu_objset_disown()**
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 
by 
**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:
https://github.com/openzfs/openzfs/pull/595#issuecomment-380919668
------------------------------------------
openzfs: openzfs-developer
Permalink: 
https://openzfs.topicbox.com/groups/developer/discussions/Tc9dce4d8b64cdd96-M9a766f1202daec5d9951582d
Delivery options: https://openzfs.topicbox.com/groups

Reply via email to