skiselkov commented on this pull request.
> + for (uint64_t i = 0; i < spa->spa_root_vdev->vdev_children; i++) {
+ vdev_t *vd = spa->spa_root_vdev->vdev_child[i];
+ vdev_trim_info_t *vti = kmem_zalloc(sizeof (*vti), KM_SLEEP);
+ vti->vti_vdev = vd;
+ vti->vti_done_cb = (void (*)(void *))spa_vdev_man_trim_done;
+ vti->vti_done_arg = spa;
+ spa->spa_num_man_trimming++;
+
+ vd->vdev_trim_prog = 0;
+ (void) taskq_dispatch(spa->spa_man_trim_taskq,
+ (void (*)(void *))vdev_man_trim, vti, TQ_SLEEP);
+ }
+ spa_config_exit(spa, SCL_CONFIG, FTAG);
+ time_update_tx = spa_trim_update_time(spa, gethrestime_sec(), 0);
+ mutex_exit(&spa->spa_man_trim_lock);
+ /* mustn't hold spa_man_trim_lock to prevent deadlock /w syncing ctx */
Correct me if I'm wrong, but can't `dmu_tx_commit` wait for `spa_sync` under
certain circumstances? I was specifically concerned with its interaction via
`spa_man_trim_stop_wait`, which might get called at certain critical junctures
(such as in `spa_vdev_enter` when removing or changing devices). I seem to
recall I saw this deadlock unless `spa_man_trim_lock` was dropped prior to
committing the transaction.
--
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/172#discussion_r116138318
------------------------------------------
openzfs-developer
Archives: https://openzfs.topicbox.com/groups/developer/
Powered by Topicbox: https://topicbox.com
