[lld][WebAssembly] Remove the experimental warning for PIC/dynamic linking (#196566)
The current dynamic linking support has been used for several years not
both in emscripten and in wasi-sdk and is documented
https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md.
We did/do have have plans to develop another version of the dynamic
linking ABI that doesn't use a global symbol namespace, and that can
still happen, but the current API is clearly production worthy
regardless of future plans.
This change removes the linker warning and the corresponding
`--experimental-pic` flag.
If we do want to still make breaking changes to the dylink format we can
rename the `dylink.1` section (which already contains a version number).
This change is leads the way for enabling shared libraries by default in
emscripten.
Linux: annotate nested xattr setattr znode locks
zfs_setattr() updates both the target znode and its hidden xattr
directory when ownership, mode, or project ID changes. The xattr
directory uses the same z_acl_lock and z_lock classes as the
parent znode, so lockdep reports recursive locking when the
second znode's mutexes are acquired.
This is a lockdep false positive rather than a real deadlock.
attrzp is the target file's hidden xattr directory, and the code
does not acquire these znode mutexes in the reverse order.
Acquire the attrzp mutexes with mutex_enter_nested() so lockdep
treats them as nested.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: ZhengYuan Huang <gality369 at gmail.com>
Co-authored-by: gality369 <gality369 at example.com>
Closes #18506
zarcstat: detect attached L2ARC device with no data
zarcstat and zarcsummary detected L2ARC presence using the l2_size
kstat, which is data held in L2ARC, not whether a cache device is
attached. When a cache device was attached but empty (freshly added,
or fully evicted):
- zarcstat rejected "-f l2*" with "Incompatible field specified!"
- zarcsummary printed "L2ARC not detected, skipping section",
hiding cumulative I/O history and health counters
Expose the existing l2arc_ndev counter as a new kstat l2_dev_count.
It is maintained by l2arc_add_vdev() and l2arc_remove_vdev(), so it
tracks attachment in real time. Use it in both tools, falling back to
l2_size for compatibility with older kernel modules.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Ameer Hamza <ahamza at ixsystems.com>
Closes #18499
shells/bash-completion: Don't depend on shells/bash{,-static}
Depending on the shell itself during build time create a large dependency
chain. E.g., using the pc file of this port requires bash being built although
technically not required at all. Have the user install bash as a direct
dependency.
PR: 292501
Tested by: michaelo
Approved by: sunpoet (maintainer)
[lldb] Add lldb.summary and lldb.synthetic decorators (#195351)
Adds two new decorators, `@lldb.summary` and `@lldb.synthetic`,
analogous to the existing `@lldb.command` decorator.
```python
@lldb.summary("MyType")
def MyType_summary(valobj, _):
return "summary string"
@lldb.synthetic("MyContainer")
class MyContainerSynthetic:
def __init__(self, valobj, _): ...
```
These decorators result in `type summary add` and `type synthetic add`
commands being run.
An additional motivation: these decorators will make it straightforward
[8 lines not shown]
NAS-140934 / 26.0.0-RC.1 / Expand sharing protocol tests for NFS (by anodos325) (#18917)
This commit converts some NFS tests into using lower-level pynfs library
to explicitly test server behavior and expands test coverage for readdir
operations.
Originally tests were executed via the linux NFS client which was
extremely limiting in how we can exercise server in a fine-grained
manner. This had the practical impact that a bug in an ACL-related
server response for non-Linux clients was undetected ( where READDIR
also requests NFS4.1 DACL -- linux never does this).
Original PR: https://github.com/truenas/middleware/pull/18912
---------
Co-authored-by: Andrew Walker <andrew.walker at truenas.com>
[libc++] Require the exact assignment expression to be trivial in __uninitialized_allocator_copy_impl
__uninitialized_allocator_copy_impl has an optimization that replaces allocator_traits::construct with std::copy for raw pointer ranges when the element type is trivially copy constructible and trivially copy assignable.
The copy-assignment trait only checks whether assignment from const T& is trivial. That is weaker than the expression used by std::copy, which evaluates *out = *in. If overload resolution selects a different non-trivial assignment operator for that expression, std::copy can call that operator on uninitialized storage.
Check is_trivially_assignable<_Out&, _In&> instead. This matches the assignment expression used by std::copy, preserves the optimized path when that assignment is actually trivial, and falls back to placement construction otherwise.
Add a regression test with a type whose defaulted copy assignment is trivial but whose templated assignment operator is selected for non-const lvalue sources.
Tested with:
~/llvm-project/build-libcxx-fresh/bin/llvm-lit ~/llvm-project/libcxx/test/libcxx/memory/uninitialized_allocator_copy_template_op_assign.pass.cpp ~/llvm-project/libcxx/test/libcxx/memory/uninitialized_allocator_copy.pass.cpp -q
[libc] Disable -march=native in CI to fix sccache poisoning (#196560)
-march=native is incompatible with shared build caches because sccache
treats it as a literal string. Object files compiled on one CPU model
get silently served to runners with a different CPU, causing SIGILL
crashes in the opt_host memory tests.
Made LIBC_COMPILE_OPTIONS_NATIVE a CMake cache variable so CI can
override it. Both overlay and fullbuild workflows now pass
-DLIBC_COMPILE_OPTIONS_NATIVE="" to disable -march=native. Local
developer builds are unaffected and still default to -march=native.
Reverted the per-CPU cache key approach from #196477 in favour of this
fix, which addresses the root cause.
Bumped sccache key versions (v2) in both workflows to invalidate the
poisoned caches.
Assisted-by: Automated tooling, human reviewed.
NAS-140905 / 26.0.0-RC.1 / Stop migration 0015 from forcing MISSION_CRITICAL profile (#18916)
Two small fixes for issues present on Goldeye:
- Migration `0015_update_profile.py` was force-setting `update.profile =
MISSION_CRITICAL` on every enterprise system regardless of the running
version's actual profile. A user upgrading from Fangtooth to a Goldeye
`EARLY_ADOPTER` release (e.g. 25.10-RC.1) was silently locked into
`MISSION_CRITICAL`. Once 25.10.3 (the first `MISSION_CRITICAL` Goldeye
release) shipped, `update.status` started returning a profile mismatch
and the `CurrentlyRunningVersionDoesNotMatchProfile` alert fired.
Migration is now a no-op; `update.config` already auto-populates
`profile` from `current_version_profile()` on first read.
- The mismatch alert was resolving profile names through
`update.profile_choices`, which filters out profiles outside the user's
product type (enterprise hides `DEVELOPER`/`EARLY_ADOPTER`). When the
running profile fell outside that filter, the alert text rendered
`<Unknown>` instead of the friendly name. Switched to resolving via
`UpdateProfiles[...].describe().name`.
[3 lines not shown]
