ffs: do not return ESTALE on attempt to ffs_unotovp() on unlinked inode
The consequences are:
- for nfs exports and fhopen(2), unlinked but still referenced inodes
are accessible
- for ffs_vput_pair() with unlock_vp = false, spurious ESTALE is not
returned when the inode is still alive but unlinked
Note that tmpfs does not return ESTALE for the unlinked nodes.
The same behavior is claimed for Linux in
https://github.com/openzfs/zfs/issues/18699
Reviewed by: rmacklem
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57982
[flang-rt] Use posix_memalign instead of std::aligned_alloc (#207248)
MallocWrapper called std::aligned_alloc for over-aligned requests, but
that C11 function is only available on macOS 10.15 and newer. flang-rt
builds with a Darwin deployment target of 10.7 (set in
AddFlangRT.cmake), so the build failed under
-Werror=unguarded-availability-new.
Use posix_memalign instead, as it is available on all supported POSIX
targets.
acpi: ignore wake button press replayed by firmware on resume
Some firmware delivers the power or sleep button press that woke the
system as an ordinary button press (Notify 0x80) shortly after resume,
rather than as the wakeup notification (Notify 0x02) the ACPI
specification requires for a button that is also a wake source.
On affected machines (e.g. the Framework Laptop 12, Intel Raptor Lake-P)
the power button is a control-method device behind the embedded
controller. The EC latches the key press that woke the system across the
sleep transition and flushes it through its normal _Qxx query path as
soon as it is reinitialized on resume. The replayed press is
indistinguishable from a genuine one, so the kernel honors it as a fresh
suspend request and the machine suspends again immediately after waking;
it cannot be kept awake with the button.
The event cannot be filtered at its source: it arrives over the same EC
query path that also carries legitimate events (lid, AC, thermal,
battery), so suppressing the drain would lose real notifications.
[24 lines not shown]
Initial import of math/cvc5 version 1.3.4.
An efficient open-source automatic theorem prover for Satisfiability
Modulo Theories (SMT) problems. It can be used to prove the
satisfiability (or, dually, the validity) of first-order formulas
with respect to (combinations of) a variety of useful background
theories.
Fix CODEOWNERS error, remove Lanza from ClangIR owners
The github project reports:
Unknown owner on line 39: make sure <name> exists and has write access to the repository
I assume Nathan's commit access lapsed and he has the `triage` role now.
I added a comment saying he is an emeritus owner. This is reversible,
and I assume if he needs or wants write access, we can revisit this in
the future.
[docs] Rename LangRef.{rst|md}
Tracking issue: #201242
This commit does not use valid markdown, so the docs will not build, but they will be fixed in an immediate follow-up commit that does the migration.
[Offload] Guard __llvm_write_custom_profile null check on non-Windows (#207170)
On Windows __llvm_write_custom_profile is defined as a strong stub (MSVC
lacks proper weak symbol support) by 09a51b2818e2, so its address is a
compile-time constant that is never null. The `if
(!__llvm_write_custom_profile)` check therefore triggers
-Wpointer-bool-conversion, which is fatal under -Werror.
Assisted-by: Claude
[Clang] Fix offsetof sign-extending unsigned array indices >= 128 (#204139)
When evaluating __builtin_offsetof with an unsigned integer array index
(e.g. uint8_t, uint16_t) whose value has the high bit set, Clang was
calling getSExtValue() on the APSInt index, which sign-extends the value
and produces a large bogus offset.
Fix this to use the correct kind of extension to extend smaller values, and to check for overflow in conversions of larger values.
Fixes #199319
AI Tool Use: GitHub Copilot (Claude Sonnet 4.6) was used to assist in
identifying the root cause of the bug in ExprConstant.cpp and drafting
the fix. The fix was reviewed, tested, and validated manually.
[BOLT] Stop materializing .dwo DIE vectors early in the pipeline
Summary: preprocessDWODebugInfo() eagerly force-extracted every .dwo
compile unit's DIE tree (getNonSkeletonUnitDIE(false)) very early in
BOLT pipeline, way before DWARFRewriter kicked in. Those vectors then
sit in memory throughout the entire rewrite pipeline, directly
contributing to BOLT's RSS peak. I did a fair amount of digging and
didn't find any reason as to why we need to keep all DIEs of DWO CU
materialized at all, since DWARFRewriter won't even read this vector
(the #197359 concurrency fix did use that, but that is unnecessary).
The problem is that these DIE trees are a massive contribution to RSS
when processing large binaries where we have 10s of K of dwos, storing
complete trees for each processed dwo.
This diff changes the #197359 concurrency fix to not rely on the DIE
sibling/children structure. It parses DWP type units selectively per
compile unit (DIEBuilder::buildDWPTypeUnitsForUnit ->
collectReferencedTypeSignatures) by finding the DW_FORM_ref_sig8
references in a unit's DIEs to decide which type units belong in that
[23 lines not shown]
