Fix dbuf dirty record traversal locking
free_verify() and dmu_buf_set_crypt_params() should hold ->db_mtx
before dbuf_find_dirty_eq(), otherwise it can race with an open
contexts dbuf_free_range().
Assert the lock is held in dbuf_find_dirty_lte() which also covers
dbuf_find_dirty_eq() to prevent future omissions.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rick Galliher <kcid at kcid.io>
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Closes #19503
raidz: compute the aggregate copy offset before adding it
vdev_raidz_io_done() found a column's data in an aggregate read buffer
with physbuf + rc_offset - prc_offset. That adds the column's device
offset to the pointer before taking off the aggregate's, so the
intermediate pointer is far outside the buffer, which is undefined.
macOS arm64e kexts are built with pointer arithmetic checks that poison
a result whose top bits differ from the base pointer. Once a child
offset was large enough to wrap the kernel heap address, the
intermediate pointer was poisoned and the memcpy() in
abd_copy_from_buf() took a data abort on a non-canonical address.
Subtract the two offsets first so only the in-bounds result is formed.
Reviewed-by: Matthew Ahrens <matt at mahrens.org>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Kamil Monicz <kamil at monicz.dev>
Signed-off-by: Joergen Lundman <lundman at lundman.net>
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Closes #19506
net-p2p/py-libtorrent-rasterbar: fix build of net-p2p/deluge-cli
net-p2p/py-libtorrent-rasterbar was building a fresh copy of
libtorrent-rasterbar.so* which was built, linked to from the
Python module's shared library, and then discarded.
The built shared lib had a different SONAME for whatever reason,
possibly due to bugs in b2, so this package wasn't finding a
compatible libtorrent-rasterbar.so* library at the run-time.
This caused a failure in deluge-cli because it couldn't install
a dependency.
This change removes the build of libtorrent-rasterbar.so* and uses
the one that is built by the dependency port.
PR: 294658
[llvm][CodeView] Don't visit anything in destructor of field list deserializer (#231287)
When a `visitKnownMember` callback errors in a field list deserializer
pipeline, we never call `visitMemberEnd` afterward - we immediately
stop.
If the `FieldListDeserializer` would call
`TypeRecordMapping::visitTypeEnd`, it would assert with [`!MemberKind &&
"Still in a member
mapping!"`](https://github.com/llvm/llvm-project/blob/0f8f2d14865a5b83a7a8ca57f63eaca64be7bbe5/llvm/lib/DebugInfo/CodeView/TypeRecordMapping.cpp#L244),
because `MemberKind` was never reset after the error.
This PR removes the call in the destructor of `FieldListDeserializer`.
It was a no-op in the success case anyway, because the reader wouldn't
be advanced. And even if it would, we only ever read from an `ArrayRef`
of the field list's data, so there's no point in caring about the
reader's position.
