NAS-144061 / 27.0.0-BETA.1 / Add bucket recovery APIs (#19873)
There are various situations in which we can have orphaned buckets.
Examples include:
* bucket is deleted and admin wants to reinstate.
* the NAS is disaster recovery instance and needs to activate buckets
after switching datasets to read-write.
This is facilited by inserting a .truenas_s3/config_backup.json file
inside each bucket (daemon-owned path) and restoring the DB row / S3
config with some user-provided overrides if required.
Two new API endpoints are added:
* sharing.s3.recoverable_buckets lists mounted datasets containing
orphaned buckets.
* sharing.s3.recover basically takes a list of datasets and rebuilds
[3 lines not shown]
[CodeGen] Re-land reverted PR (#216510): "Use RegisterClassInfo for remaining allocation-order users" (#222450)
Re-land PR #216510 which was reverted in #221749 and fixed by @mhalk in
#221849.
Additionally addresses the comment in the reversion PR to fix
`/llvm/test/CodeGen/AArch64/wineh-try-catch.ll` with -regalloc=pbqp by
refreshing RCI with updateReservedRegs from my previous PR.
Edit: Removed PBQP related items from this PR.
Assisted by composer 2.5
[AMDGPU] Make GFX1250VALUBlockingCycles a feature. (#226314)
Included (intentional) behavior change: gfx1251 (w/ FullRate64Ops) does
not have GFX1250VALUBlockingCycles feature --- table is only partially usable for
gfx1251.
devel/protobuf-c: update to 1.5.2
Update protobuf-c to version 1.5.2:
* Chase compatibility issues with Google protobuf 30.0-rc1 by @edmonds
in #762
* protoc-gen-c: Explicitly construct strings where needed for protobuf
30.x by @edmonds in #768
Add autoreconf.
Add a small patch to fix the symbol versioning bug. The patch will
be submitted upstream as well.
Fetch GitHub release tarball. (truckman)
PR: 298768
Sponsored by: DomainTools LLC
Export zpool_valid_proplist from libzfs
zpool_create checks pool properties with zpool_valid_proplist before it
asks the kernel to create the pool. The function is static, so a caller
that wants to check pool properties ahead of time, such as a dry run of
pool creation, has to copy its rules and keep them in step by hand.
Make the function public and move prop_flags_t, the flags it takes, to
libzfs.h. The function itself is unchanged. Update libzfs.abi to match.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Ameer Hamza <ahamza at ixsystems.com>
Signed-off-by: Caleb St. John <30729806+yocalebo at users.noreply.github.com>
Closes #19190
libzfs_core: block delivery of SIGUSR1 in send_worker thread
This fixes a Linux-specific bug.
3a909fe33 (libzfs, libzfs_core: send: always write to pipe, 2022-02-21)
introduced a subtle bug where zfs send -RPv would not print status
information periodically anymore when the stdout is redirected to
something that isn't a pipe (e.g. >/dev/null).
This is because the send_worker thread introduced by this commit
is created with an unmodified signal mask from libzfs. When
zfs_send_space is called it creates this thread. When we request
verbose status information another thread is created which, in
theory, should periodically receive a SIGUSR1 via a POSIX timer.
The main thread blocks USR1 delivery *after* the creation of the
progress thread, leaving the send_worker thread's signal mask
unmodified. The delivery of SIGUSR1 is now random and for at least
Debian Trixie with kernel 6.12.107+deb13-amd64 this causes the
[12 lines not shown]
ipmi: Add some additional diagnostic output on errors
Add some additional diagnostic output for IPMI code,
particularly on error paths. This has been found to be helpful at
$WORK and seems generally useful, so contributing the changes back to
upstream.
Sponsored by: Dell Technologies
Reviewed by: vangyzen@
Differential Revision: https://reviews.freebsd.org/D60091
[flang][Test] Cover the lowering of loops with a non-terminating body
A previous change leaves such a loop unstructured. Check what that produces:
the cycle survives as a block branching to itself, no fir.do_loop is emitted
for the loop control, and a loop that only needs a block of its own still
gets the structured form with its body in a region.
[flang] Lower loops whose branching is confined to their body structurally
Such a loop was classified separately by a previous change but still
lowered as unstructured, so its structured form was lost.
Lower it structurally instead, with its body folded into a region that can
hold the branching. The loop keeps its bounds on the op, so it remains
available to whatever transforms or parallelizes it. Only the body is
folded: the loop control statements are emitted as they are for any
structured loop, since a branch from outside may target either of them.
Loops an OpenACC or OpenMP directive owns are lowered the same way, so
they keep their form too.
[flang] Honor the execute-region wrap flag when detecting loop internals
A loop whose branching is confined to its body is lowered with that body
in an scf.execute_region, since the CFG needs more than the single block
fir.do_loop's region admits. With the wrap disabled there is nowhere to
put those blocks, so skip the reclassification and leave the loop
unstructured.
[flang] Keep loops with a non-terminating body unstructured
A loop body that cannot run to completion must not be folded into an
scf.execute_region: the region carries no memory effects, so DCE deletes
it outright, dropping the non-termination and letting execution fall past
the loop. Branches survive that, being terminators.
An infinite DO was already rejected. Follow chains of unconditional GO TOs
as well and reject a body whose chain closes on itself, which is the same
bound the cf.br canonicalization applies to cyclic branches.
[flang] Detect loops whose branching is confined to their body
A DO loop is classified as either structured or unstructured, and a single
raw branch anywhere in its body forces the loop -- and every construct
enclosing it -- onto the unstructured path.
That is stronger than necessary. A loop keeps its structured control flow
as long as its branching neither leaves its body nor enters it from
outside. Classify such a loop separately from a fully unstructured one.
This only classifies: lowering is unchanged. PFT dumps mark the new
classification with '~', which is what the tests key on.
[flang] Resolve an assigned GO TO's targets from the completed assign map
An assigned GO TO reaches any label ASSIGNed to its variable, and a label
list does not bound that: lowering allows a branch to any ASSIGNed label
whether or not the list names it. Branch analysis only sees the ASSIGNs
preceding the GO TO in program order, so the successors it records, and the
incoming branches derived from them, can be incomplete.
The symbol-to-labels map is complete once branch analysis has finished,
which is when the classification runs. Ask it for the full target set
instead of trusting the recorded successors, so a loop whose assigned GO TO
stays within its body is still recognised.
[flang] Record the evaluations that branch to each evaluation (#225755)
The PFT records where each branch goes, but not where it comes from, so
asking whether anything branches into a construct means walking the
whole procedure.
Record the reverse edges beside the forward ones, and print them in PFT
dumps so both directions of the branch graph are visible.
userspace: remove makedev detection and cleanup headers
makedev() is defined in sys/sysmacros.h on Linux, and sys/types.h on
FreeBSD. However, nothing in any of our userspace code actually uses it,
so all the supporting edifice isn't actually used.
Worse though, the SPL sys/sysmacros.h defines a lot more in userspace
than in kernel, and since sys/types.h would pull it in directly to keep
up the appearance that makedev() is in sys/types.h, it's not always
clear where some of those things in sysmacros.h are coming from, or
_should_ come from.
So clean this up. Remove the the makedev config tests, the empty mkdev.h
header, and the inclusion of sysmacros.h from types.h. For those things
that actually needed some of those definitions, include sysmacros.h
directly.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #19204
[AMDGPU] Price scalar integer to fp casts by source width and sign
Scalar sources between a byte and 31 bits fell to the default cost of one
while the matching vector lanes were already priced, which skewed the
difference SLP weighs a bundle against. Such a source is extended before
the conversion, and what the extension takes depends on the width, on the
sign and on whether the subtarget has SDWA and 16 bit instructions.
Sources narrower than a byte are left alone, because their vector form is
not priced either.
[AMDGPU] Price narrow integer to bfloat vector casts
A vector lane of 9 to 15 or 17 to 31 bits converted to bfloat got the
generic cost, which leaves out the rounding. Such a lane is converted to
f32 first like any other narrow lane, so price it as the f32 conversion of
the same source plus the rounding. Lanes of 8 and 16 bits keep their cost.
[AMDGPU] Model the cost of the expanded integer to/from floating point casts
No instruction converts to or from a 64 bit integer, and narrow vector
lanes are converted one at a time. Price these expansions by the FP64
rate, sdwa and 16 bit instruction support, and price i33 to i63 like
i64 and bf16 like f32 plus rounding.
Assisted-by: Claude Code Opus 5
[NFC][AMDGPU] Add cost tests for narrow integer to fp casts
Covers integer sources from a byte to 31 bits converted to half, float,
bfloat and double, as vector lanes and as scalars, over the subtarget
combinations that change the expansion. The existing cast tests get the
same subtarget coverage and the cases they were missing. The costs
recorded here are the ones the model reports today.
[llvm] Unify python shebangs (#187255)
As per PEP-0394[1], there is no real concensus over what binary names
Python has, specifically 'python' could be Python 3, Python 2, or not
exist.
However, everyone has a python3 interpreter and the scripts are all
written for Python 3. Unify the shebangs so that the ~50% of shebangs
that use python now use python3.
[1] https://peps.python.org/pep-0394/
