[illumos-gate] 14716 viona should support a control queue and promiscuous mode. -- Andy Fiddaman <illumos⊙fn>

ooh all ghe

*the stuff in omnios is now upstream

*bhyve

Just in time to start on the next batch!

Are bHyves like cookies? Cooked in batches?

They're more like a rash.

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."

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?

Then again, mutex_owned() in `usr/src/uts/common/os/mutex.c` looks racy to me. :/

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.

For adaptive mutexes we always know who the owner is. For spin locks we don't.

I do not believe ZFS uses spin locks at all and given how libfakekernel is doing emulation, it can ignore the distinction.

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.

It's a debugging aid, but not a panacea or a promise.

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.

though we should probably go through and make note re: VERIFY and such

It looks like we have a fair few VERIFY(MUTEX_HELD()) in uts

well, not that many, and mostly in recent code

I probably wrote them, lol

smrt, ccid, amdzen, ena, vioblk...

hey I'm not alone

rzezeski: you should be

in the woods

by yourself..... with bear spray

[illumos-gate] 14541 nvme_quiesce() can hang preventing reboot -- Jordan Paige Hendricks <jordan⊙oc>

Folks ^^^ is a helluva writeup.

fenix illumos 14541

BUG 14541: nvme_quiesce() can hang preventing reboot (Closed)

↳ illumos.org/issues/14541 | code.illumos.org/c/illumos-gate/+/2129

reviewers of 15374 (fenix?)

I just bumped it to add #15413 to the message (fenix?)

BUG 15413: amd64 panic stack size gets screwed by assembler/cpp (New)

↳ illumos.org/issues/15413 | code.illumos.org/c/illumos-gate/+/2632

if anyone wants to follow along and agree/disagree with me, that would be nice

and many thanks for dan getting me to do object diffs in a way that make that not get lost in the soup

(YW)

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().

Hi danmcd. Long time no see.

Hi. Pardon shortness, I have to run in 5-10mins to head out an pick up a kid fro the weekend.

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.

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.

if it's a particular lock, couldn't you ASSERT(mutex_tryenter(&lock)) ?

yeah it means you're holding the lock now, but that also means no one else is

and tryenter would prevent blocking

maps

Sorry

and it's probably semantics that I suspect are probably at least somewhat portable

(freebsd at least has an equivalent)

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".

getting it right would mean needing a mutex that protected your other mutex

I seem to recall meem had a great blog post about such things.

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.

on a _non-debug_ kernel, is there anything that will normally run `modunload -i 0` ?