Yes, you are right, probably it should be easier to just fix the syseventd.
Closing.
--
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/433#issuecomment-320493157
---
Closed #433.
--
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/433#event-1194413075
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/gr
W.r.t. these changes, if a racing thread did not acquire a write lock through
rw_trywrlock, then were any error to occur for the active writer, it seems the
waiting reader is uninformed and goes on its way as though libzfs_ns_avl is
ready to use.
(As an aside regarding the pre-existing code, I
This is the one we have been hitting with syseventd, so instead of rewriting
large parts syseventd's zfs_mod I choose to at least try to make libzfs a bit
more MT-aware.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https
libzfs is generally MT-unsafe. If these two threads are using the same
libzfs_handle_t, things are going to go badly for many reasons, not just due to
concurrent manipulation of libzfs_ns_avl. What's the rationale for adding
locking to only this one part of libzfs?
--
You are receiving this
I don't think the failed test case is related to this change, running the
utils_test section locally passes all tests:
```
$ sudo rm -rf /var/tmp/test_results/ && /opt/zfs-tests/bin/zfstest -ac utils.run
Test: /opt/zfs-tests/tests/functional/utils_test/setup (run as root) [00:05]
[PASS]
Test: /op
LGTM.
--
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/433#issuecomment-318303586
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/gro
