libthr: require both _Unwind_ForcedUnwind and _Unwind_GetCFA for !PIC
Static linking must bring in both symbols for the unwind to work.
The landing pads added by 2734bbbcba3c reference _Unwind_Resume and
__gcc_personality_v0. In a static link, these pull UnwindLevel1.o
from libgcc_eh.a, which also defines _Unwind_ForcedUnwind, but
not UnwindLevel1-gcc-ext.o, which defines _Unwind_GetCFA. Unless
something else pulls that object in, as libcxxrt does for C++ programs,
thread_unwind_stop() calls a NULL _Unwind_GetCFA on every thread exit.
Reported and tested by: dch
Fixes: 2734bbbcba3c ("libthr: Create landing pad in thr_once in C++ exception")
Sponsored by: The FreeBSD Foundation
[lldb] Only create PDB symbol files for PE/COFF and PDB object files (#239739)
`SymbolFileNativePDB::CalculateAbilities` calls `loadMatchingPDBFile` on
the module file path for every object file it is offered, which runs
`llvm::object::createBinary` on the whole file. For non-PE modules
without full DWARF this is pure overhead, and for objects embedded in a
larger file it parses the entire container once per module.
The PDB readers can only produce symbols from a PE/COFF image with a
debug directory or from a PDB file, so reject every other object file in
CreateInstance.
Co-authored-by: Bar Soloveychik <barsolo at fb.com>
18440 adt_cpy_tid() swaps the terminal device maj/min in 64-bit processes
Reviewed by: Robert Mustacchi <rm at fingolfin.org>
Approved by: Gordon Ross <gordon.w.ross at gmail.com>
net-mgmt/xymon-server: Remove LDAP from default port options
NETSNMP was intentionally added, but LDAP was leftover by mistake after
build testing.
SNMP monitoring is a commonly used feature and often handled by net-mgmt/devmon
for monitoring network gear. Some SNMP monitoring tasks can be handled
natively in Xymon without needing devmon, so the NETSNMP port option
remains as default.
I have never had a request over many years of maintainership to enable
LDAP by default nor have I ever witnessed it being used in any
production environments. If this change is of interest to you, please
file a PR or contact me.
NVPTX: Remove dead kill flag clearing in NVPTXProxyRegErasure (#239776)
The replaced registers are virtual, which can no longer carry kill flags.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
raidz: refuse too small replacements during expansion
While a raidz expansion is in progress, `zpool replace` of a raidz
child accepts a device that is too small. The resilver or the reflow
then writes past the end of the new device, tripping this VERIFY in a
debug build (or writing past the end of the device otherwise):
VERIFY3U(rc->rc_offset + rc->rc_size, <,
cvd->vdev_psize - VDEV_LABEL_END_SIZE) failed
PANIC at vdev_raidz.c:vdev_raidz_io_start_write()
Reproducer:
truncate -s 1G /var/tmp/d{1..4}; truncate -s 800M /var/tmp/small
zpool create tank raidz1 /var/tmp/d1 /var/tmp/d2 /var/tmp/d3
zfs set compression=off tank
dd if=/dev/urandom of=/tank/f bs=1M count=1200; zpool sync tank
zpool replace tank /var/tmp/d1 /var/tmp/small # "device is too small"
echo 1 > /sys/module/zfs/parameters/raidz_expand_max_reflow_bytes
[40 lines not shown]
ZTS: test too small raidz replacement during expansion
Add raidz_expand_012_neg, which pauses a raidz expansion and checks
that 'zpool replace' refuses a device too small for the not yet
reflowed, narrower part of the vdev, including after an export/import
with the expansion still paused. It then checks that a device of the
original size is accepted, and that the pool scrubs clean once the
expansion completes.
This currently fails: the too small device is accepted, and the resilver
or reflow then writes past its end (a VERIFY panic in
vdev_raidz_io_start_write() on debug builds). The fix follows in the
next commit.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Will Rouesnel <wrouesnel at wrouesnel.com>
Closes #19279
AArch64: Use the DAG's libcall info in call and DAG lowering
Libcall info should come from the analysis pass, and the static copy
in TargetLowering will be removed.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[BOLT] Drop secondary entrypoint after e843419 veneer is inlined (#239313)
Due to the lld generated Cortex-A53 erratum 843419 veneer, the caller
function has a second entrypoint at the veneer's branch-back target.
After the veneeer is inlined, we can remove this second entrypoint if
it has no other external reference, so it won't make the function be
treated as a multi-entry function.
ZTS: let udev settle before zfs_copies destroys the volume
zfs_copies_006_pos fails now and then in CI right after unmounting
the ext2 file system on its volume:
cannot destroy 'testpool/testvol1': dataset is busy
ERROR: zfs destroy testpool/testvol1 exited 1
new_fs writes the volume and closes it, so udev's watch on zd* makes
it rescan the volume, and blkid holds the device open while it does.
The test waits for udev before new_fs but not after it, and a destroy
issued while that scan still has the volume open gets EBUSY. The
cleanup's destroy_dataset, which retries, succeeds a moment later.
do_vol_test() is shared with zfs_copies_003_pos, whose zpool create
also writes the volume.
Wait for udev with block_device_wait before the destroy and retry it
while it is busy, the way alloc_class_016_pos and destroy_dataset do.
The destroy must still succeed.
[3 lines not shown]
zap: Fix zap_trunc() to account next ptrtbl blocks
In zap_trunc(), a case involving the expansion of ptrtbl was overlooked.
As a result, freeblk could end up pointing out to a block that had been
allocated for next ptrtbl. A next leaf allocation would lead to ptrtbl
corruption.
The fix checks whether ptrtbl is being expanded and accounts the blocks
allocated for it to compute freeblk.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Alexander Stetsenko <alex.stetsenko at gmail.com>
Closes #19591
Closes #19693
Linux: unhash zero-link znodes when resuming after rollback
zfs_resume_fs() calls zfs_rezget() for every cached znode after a
rollback or a receive into a mounted filesystem. If zfs_rezget()
fails, the inode is unhashed so that a new object created with the
same number does not collide with it.
zfs_rezget() can also succeed for an object that has zero links in
the new state: a file that was open-unlinked when the snapshot was
taken and is still held open. It then sets z_unlinked and drops the
SA handle, but the inode stays hashed. The unlinked drain that runs
after resume finds no znode attached to the object, so it allocates a
new unhashed one and frees the object. When the object number is
reused, insert_inode_locked() finds the old inode and fails:
VERIFY0(insert_inode_locked(ip)) failed (-16)
PANIC at zfs_znode_os.c:641:zfs_znode_alloc()
The panicking thread holds an assigned transaction, so txg_quiesce
[13 lines not shown]
ZTS: test rollback with held open-unlinked files
A file that is open-unlinked when a snapshot is taken is a zero-link
object in that snapshot's unlinked set. If the file is still held
open when a mounted filesystem is rolled back to the snapshot,
zfs_rezget() succeeds for it, and the unlinked drain that runs after
resume frees the object while the old inode is still in use.
Add zfs_rollback_held_unlinked, which holds open-unlinked files across
a snapshot and a mounted rollback, then creates files until one reuses
a held object number. It also checks that a write through a stale
descriptor fails and does not modify the new file.
This currently fails on Linux: the create that reuses the object
number fails VERIFY0(insert_inode_locked(ip)) in zfs_znode_alloc()
with EBUSY, because the old inode is still hashed. The fix follows
in the next commit.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[3 lines not shown]
ZTS: Race fallocate against a buffered append too
zpl_iter_write() takes no inode lock for a buffered write either, so
a buffered write that extends the file races fallocate the same way an
O_DIRECT one does.
dio_append_fallocate gains -b, which makes the append a buffered write
instead of an O_DIRECT one. fallocate_odirect_append runs each of the
extend, punch and zero modes with both, and names the buffered ones
buffered-MODE when they lose a round. The buffered runs use 1000
rounds instead of 100: their window is shorter, and with 100 rounds
some runs on master lost none.
On a debug build of master the test failed 10 of 10 runs, and the
buffered runs lost 21 to 952 of 1000 rounds in every mode of every
run. With the fallocate change in this PR it passed 10 of 10, and no
round was lost.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
[5 lines not shown]
SelectionDAG: Get libcall info from analysis, not TargetLowering
TargetLowering's copy of the libcall info will eventually be
removed. Use the LibcallLoweringInfo analysis from SelectionDAG
instead.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Linux: do not truncate a concurrent extending write in fallocate
zpl_iter_write() takes no inode lock, so a buffered or O_DIRECT write
that extends a file updates the file size without holding it. A
fallocate that extends the file reads the size into olen first. If
the write grows the file after that, the fallocate truncates it back
to offset + len, the written data is gone, and the application was
told its write succeeded.
The extend path set the new size with zfs_freesp(zp, offset + len, 0,
0, TRUE). With len 0, zfs_freesp() sets the size to off. It grows the
file when off is past z_size and truncates it otherwise. The write had
already moved z_size past offset + len, so this took the truncate
branch.
zfs_freesp() could also lose the write when it read z_size before the
write raised it. zfs_extend() then found the file long enough and did
nothing, but zfs_freesp() still logged TX_TRUNCATE at offset + len and
called truncate_setsize(), so i_size went short and replay would cut
[23 lines not shown]
ZTS: Race fallocate against a concurrent O_DIRECT append
fallocate_odirect_append runs a new helper, dio_append_fallocate.
Each round writes one 128 KiB block, then appends another with
O_DIRECT while a second thread calls fallocate, and checks that the
file still holds the appended block. The test runs 100 rounds each of
an extending fallocate, a keep-size punch at EOF and a keep-size
zero-range at EOF, logs each mode's count, and fails naming every
mode that lost a round. It sets recordsize=128k and direct=standard
so the append takes the Direct I/O path. It runs on Linux only.
On a debug build of master it failed 10 of 10 runs. In the last one,
every mode lost all 100 of its 100 rounds.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Will Rouesnel <wrouesnel at wrouesnel.com>
Reviewed-by: Tigerblue77 <37409593+tigerblue77 at users.noreply.github.com>
Signed-off-by: Patrick Domack <patrickdk at patrickdk.com>
Closes #19344
[SLP][REVEC]Use scalar lane type for buildvector lists
The REVEC lane type of an insertelement is its vector type, so the
"no actual vectorization" check skipped every VF and the buildvector
of loads was never vectorized.
Fixes #239546
Reviewers:
Pull Request: https://github.com/llvm/llvm-project/pull/239825
zap: don't use a stale ptrtbl shift in zap_shrink()
zap_shrink() computed prefix_diff = zt_shift - prefix_len at the top of
each loop iteration, from a zt_shift sampled when the function was
entered. When zap_lock_try_upgrade() fails, zap_lock_upgrade() drops
zap_rwlock and waits for it as WRITER. zt_shift was re-read after that,
but prefix_diff, already computed from the old value, was not, and it is
what the collapse uses:
idx = (slbit ? prefix : sl_prefix) << prefix_diff;
nptrs = 1ULL << prefix_diff;
While the lock is down, a concurrent fzap_add() can grow the pointer
table (zap_expand_leaf() / zap_put_leaf_maybe_grow_ptrtbl() ->
zap_grow_ptrtbl(), zt_shift++). Growing the table doesn't change any
leaf's prefix or prefix_len, so the checks done after relocking (both
leaves still empty, still at prefix_len) still pass. zap_shrink() then
points a range of the wrong size at the wrong index at the surviving
leaf. The removed prefix is always odd, so the stale range never
[30 lines not shown]
zap: test zap_shrink() with ptrtbl growth via a test-only tunable
zap_shrink() can drop zap_rwlock while upgrading it to WRITER, and
another thread may grow the pointer table in that window. That only
happens under a narrow race, so nothing in the test suite exercises it.
Add zap_shrink_test_grow_ptrtbl, a test-only module parameter
(default 0). While it is nonzero, each zap_shrink() that has to upgrade
its lock takes the path where the in-place upgrade failed and grows the
pointer table after reacquiring the lock, as a concurrent
zap_expand_leaf() could have done. Each use decrements it, so a test
can bound how often the table grows. The check is only made when
zap_shrink() is about to collapse two leaves.
Add zap_shrink/zap_shrink_002_pos, which fills a directory, sets the
tunable, removes every file, checks that the pointer table grew, and
then creates and removes the same files again, checking that every
name is found and that the ZAP shrinks back to a single leaf.
[4 lines not shown]
