13:00:25 [illumos-gate] 14716 viona should support a control queue and promiscuous mode. -- Andy Fiddaman 17:34:07 ooh all ghe 17:34:18 *the stuff in omnios is now upstream 17:34:22 *bhyve 18:35:00 Just in time to start on the next batch! 18:42:10 Are bHyves like cookies? Cooked in batches? 18:43:42 They're more like a rash. 19:08:17 This suggests to me that if any thread is holding a lock, mutex_owned() will return true: "mutex_owned() should only be used in ASSERT() and may be enforced by not being defined unless the preprocessor symbol DEBUG is defined. Its return value is non-zero if the current thread (or, if that cannot be determined, at least some thread) holds the mutex pointed to by mp." 19:08:22 https://docs.oracle.com/cd/E88353_01/html/E37855/mutex-owned-9f.html 19:09:05 The kernel code also seems to correspond to that. However, in OpenZFS and libfakekernel, this is implemented as `(mutex_owner(mp) == current)`. Would others agree that the implementations in OpenZFS and libfakekernel are wrong? 19:12:04 Then again, mutex_owned() in `usr/src/uts/common/os/mutex.c` looks racy to me. :/ 19:14:56 So there are different types of mutexes that exist that are determined based on how you create them due to the IPL in the kernel in illumos. 19:15:18 For adaptive mutexes we always know who the owner is. For spin locks we don't. 19:15:50 I do not believe ZFS uses spin locks at all and given how libfakekernel is doing emulation, it can ignore the distinction. 19:17:30 I mean, inherently there will always be a chance of race or someone can illegal unlock it right after you've made the ASSERT call. 19:18:17 It's a debugging aid, but not a panacea or a promise. 19:24:25 I'm pretty sure in our documentation, near the bit you quoted, we make extra effort to say "You can't use this for things that aren't ASSERT", even more than in the part you quoted. 19:24:49 though we should probably go through and make note re: VERIFY and such 19:27:54 It looks like we have a fair few VERIFY(MUTEX_HELD()) in uts 19:29:26 well, not that many, and mostly in recent code 19:29:33 I probably wrote them, lol 19:30:03 smrt, ccid, amdzen, ena, vioblk... 19:31:04 hey I'm not alone 20:03:18 rzezeski: you should be 20:03:21 in the woods 20:03:27 by yourself..... with bear spray 20:05:05 [illumos-gate] 14541 nvme_quiesce() can hang preventing reboot -- Jordan Paige Hendricks 20:06:12 Folks ^^^ is a helluva writeup. 20:06:22 fenix illumos 14541 20:06:23 BUG 14541: nvme_quiesce() can hang preventing reboot (Closed) 20:06:24 ↳ https://www.illumos.org/issues/14541 | https://code.illumos.org/c/illumos-gate/+/2129 20:07:10 reviewers of 15374 (fenix?) 20:07:20 I just bumped it to add #15413 to the message (fenix?) 20:07:33 BUG 15413: amd64 panic stack size gets screwed by assembler/cpp (New) 20:07:33 ↳ https://www.illumos.org/issues/15413 | https://code.illumos.org/c/illumos-gate/+/2632 20:07:58 if anyone wants to follow along and agree/disagree with me, that would be nice 20:08:14 and many thanks for dan getting me to do object diffs in a way that make that not get lost in the soup 20:09:59 (YW) 20:15:47 rmustacc, richlowe: Thanks. I will refrain from changing the OpenZFS code to try to match the illumos kernel more closely, although I am adding a mutex_owner() implementation to my local branch since I want to do an assertion that no one is holding a lock in vdev_free(). 20:16:31 Hi danmcd. Long time no see. 20:17:02 Hi. Pardon shortness, I have to run in 5-10mins to head out an pick up a kid fro the weekend. 20:32:45 I can't speak for other operating systems, but I don't think ZFS will ever do a high-priority mutex that becomes a spin lock and therefore basically treating it as owned or not is fine. 20:33:15 I would only ever assume that you can answer if the thread in question is holding the lock or not. I don't think trying to ask is anyone holding this is going to work. 21:35:18 if it's a particular lock, couldn't you ASSERT(mutex_tryenter(&lock)) ? 21:35:40 yeah it means you're holding the lock now, but that also means no one else is 21:35:51 and tryenter would prevent blocking 21:36:26 maps 21:36:40 Sorry 21:38:47 and it's probably semantics that I suspect are probably at least somewhat portable 21:38:54 (freebsd at least has an equivalent) 21:39:29 the basic theory is "You can't get it right, make it clear it can't be right, tell people to only use it in the case where it's possibly useful". 21:39:45 getting it right would mean needing a mutex that protected your other mutex 21:39:56 I seem to recall meem had a great blog post about such things. 22:31:11 rmustacc: We actually have that implicitly on Linux. Unless the kernel has been built in a way that disables it, all Linux kernel mutexes are adaptive mutexes. 23:57:37 on a _non-debug_ kernel, is there anything that will normally run `modunload -i 0` ?