pppoe(4): leverage if_hardmtu for RFC 4638 instead of parent if_mtu
Interfaces operate at their maximum supported packet size at all times,
independent of the software IP stack MTU.
Enforce MTU ceilings during PPPOESETPARMS and SIOCSIFMTU based on
if_hardmtu instead of the parent's software if_mtu. This allows pppoe(4)
devices to use "mtu 1500" without requiring manual MTU manipulation on
the physical parent interface. Update pppoe.4 to match.
"if it works for you then it's ok by me" dlg
[MC][AsmParser] Check .lto_discard before parsing the assignment (#204025)
I was deeply stumped, so I asked an LLM to help me track down this Linux
kernel build failure:
https://lore.kernel.org/all/202606122021.pA9TozrA-lkp@intel.com/
The bug only surfaced for Full LTO with 2+ TUs because that is when the
LTO merger emits ".lto_discard SYM" between two duplicated module-asm
blocks; ThinLTO compiles each module separately so the merged-asm
pattern does not arise, and a single TU has nothing to discard. Hit in
practice by the Linux kernel via -fsanitize=kcfi: every TU that
address-takes an externally-defined function emits the same ".weak X;
.set X, HASH" pair via module asm, so any >1-TU kcfi build with Full LTO
failed to link with "undefined symbol" against the kcfi type id.
parseAssignment checked discardLTOSymbol after
parseAssignmentExpression, which is too late for the common "preserve
first, discard later" pattern that the LLVM LTO library emits when
multiple bitcode inputs each carry the same weak symbol definition
[19 lines not shown]
Ensure oath users file entries are always valid
If we have an invalid TOTP entry (interval not supported by
liboath) then lookups will fail with OATH_UNKNOWN_USER, which
is an incorrect response when we'd expect rather to have an
explicit failure mode. API model / more thorough changes are
tracked in NAS-141431.
[AArch64] Compact scalable-vector intrinsic maps (#202618)
SVE and SME code generation only reads BuiltinID, LLVMIntrinsic, and
TypeModifier from its generated intrinsic maps. Store those fields in a
16-byte ARMScalableVectorIntrinsicInfo instead of the 32-byte
ARMVectorIntrinsicInfo used by NEON and SISD code generation. Update
both the classic and CIR consumers.
On an LLVM 22.1.7 arm64 release build, stripped standalone clang shrinks
from 115,097,192 to 114,816,456 bytes, saving 280,736 bytes (0.244%).
Work towards #202616
AI tool disclosure: Co-authored with OpenAI Codex.
Linux 7.1 compat: META (#18682)
Update the META file to reflect compatibility with the 7.1
kernel.
Signed-off-by: Tony Hutter <hutter2 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Reviewed-by: Chris Longros <chris.longros at gmail.com>
Revert "[IRTranslator] Precommit tests for bitcasts of the byte type #203638 (#204378)
This reverts commit 7e5bc4c7bd23e390cdb0b08f807968ea256b0df2 as the
MachineVerifier identifies 'bad machine code'.
[libc++] Document post-WG21-meeting conformance update procedure (#204357)
This patch adds a section in the documentation to explain the procedure
to follow after a WG21 meeting to properly track papers. This should
clear out some confusion about how this process happens and who should
be responsible for doing it.
[lldb] Fix race in macOS's FindProcessesImpl (#204109)
Our current FindProcessImpl has a TOCTOU bug where we first query the
buffer size we should provide via sysctl and then later pass a buffer
with that size to be filled. If the list of processes grows larger than
the buffer we pass, then our current implementation fails by returning
an empty list of processes. This race only happens rarely in practice as
we pad the buffer size with 10 additional entries to account for some
process growth.
This patch replaces this logic by a backoff loop that retries fetching
the process list if our buffer is too small (sysctl tells us if this is
the case by setting ENOMEM). This new implementation can only fail in
the system consistently spawns thousands of new processes between
each retry.
This should fix the actual root-cause for the random failures in
TestSimulator.py
[NVPTX] Fix build break from #201217 (#204380)
#201217 added a third `SymbolSize` argument to `AggBuffer::addSymbol()`
but missed one call site, which was added by 98160521cb72 after the PR
branch was cut. Pass `AllocSize` like the sibling calls do.
NAS-141417 / 27.0.0-BETA.1 / Convert hardware plugin to the typesafe pattern (#19145)
## Context
The hardware plugin is a directory of four mostly-private legacy
services (mseries.bios, mseries.nvdimm, hardware.memory, plus
hardware.virtualization). Only hardware.virtualization.variant is public
over the wire; the rest return plain dicts/bools consumed internally by
alert sources and usage reporting, so Pydantic models would be pure
overhead.
## Solution
Applied the port-plugin pattern: lean Service shims in __init__.py that
delegate to plain, fully type-annotated module functions, keeping the
existing dict/primitive return shapes so no consumer changes are needed.
The one public method gets check_annotations=True against the existing
HardwareVirtualizationVariant models. Registered the services in
main.py's ServiceContainer via nested hardware/mseries containers and
added the plugin to mypy.yml.
[AMDGPU] Remove unnecessary and broken sign/zero-extension (#203436)
When expanding div/rem by using floating-point operations,
sign/zero-extending the result from the calculated DivBits input width
to 32-bits is unnecessary. CreateFPToSI or CreateFPToUI is called with a
32-bit int type so the conversion instruction will already produce a
result with the desired width.
Also it is incorrect. For signed-division `DIVBITS_MAX_NEG/-1`, the
result should be `-DIVBITS_MAX_NEG` a positive value. Sign-extension
will incorrectly return a negative result. For example, for DivBits=4,
`-8/-1 = 8`, but adding code to do a 28-bit sign-extension will
incorrectly return `-8`.
Tested in https://github.com/llvm/llvm-test-suite/pull/423.
---------
Signed-off-by: John Lu <John.Lu at amd.com>
[M68k] Do not allow addressing modes k and q as MOVE targets (llvm#200826) (#201653)
This is intended as a fix for #200826 by removing PC-relative address
modes from the m68k MOVE patterns. It also affects MOVEM, and the
"atomic store" pattern that maps to the respective MOVE instruction as
well. This patch is based on the big patch authored by Gemini at
https://github.com/llvm/llvm-project/issues/181481#issuecomment-4476933700
, but as has been carefully trimmed to just address one single issue,
and every change has been verified to make sense. Gemini also restricted
the list of source addressing modes for MOVEM to the valid destination
addressing modes, which is not required according to the Motorola
specification.
[llvm-exegesis] Add did-you-mean hint for unknown opcodes (#203463)
Fixes #203199
When skipping a benchmark entry with an unknown opcode name, suggest the
nearest matching opcode if the edit distance is <= 1 (similar to
OptTable::findNearest).
Example:
```text
warning: skipping benchmark entry: No opcode with name 'VADDPDYrrr' - did you mean 'VADDPDYrr' ?
```
And Tested with:
- `llvm-lit
llvm/test/tools/llvm-exegesis/X86/analysis-unknown-opcode-did-you-mean.test`
- `llvm-lit
llvm/test/tools/llvm-exegesis/X86/analysis-skip-unknown-opcode.test`
[2 lines not shown]
