Fix a kernel panic in DTrace's rw_iswriter subroutine. On FreeBSD the sense of rw_write_held() and rw_iswriter() were reversed probably due to a cut and paste error. Using rw_iswriter() would cause the kernel to panic.

[markj]

sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c

4394 ↗

(On Diff #22729)

I know this isn't a new bug, but I think this is wrong: lc_owner will set lowner to some non-NULL value even if the lock is held shared. For instance, owner_sx() sets

*owner = (struct thread *)SX_OWNER(sx->sx_lock);

and if sx has shared holders this value will be non-zero.

[markj]

sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c

4394 ↗

(On Diff #22729)

Also this is somewhat incorrect as it calls into the kernel from DTrace probe context. That is, there's nothing preventing one from putting a probe on the lc_owner() implementation for a given lock class. Probably we could just blacklist those functions when FBT creates probes.

[gnn]

sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c

4394 ↗

(On Diff #22729)

It probably makes the most sense to split out the RW_WRITE_HELD case from the SX_EXCLUSIVE_HELD case and proceed to fix this from there.

I think the blacklisting mentioned in your second comment can be done as a separate change.

[markj]

sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c

4394 ↗

(On Diff #22729)

I'm not sure that's necessary? I think owner_sx() and owner_rw() just need to set owner to NULL (but keep the same return value as before) if the lock is held shared. That can probably be fixed separately too, so I don't see anything wrong with committing this as-is.