When a leaf vdev cannot be opened during pool import, the kernel marks
it ZPOOL_CONFIG_NOT_PRESENT and libzfs degrades its display name to the
bare guid instead of a device path. pool.transform_topology derives
`path` from that name, so the vdev ends up with `path: None`, and
pool.find_disk_from_topology crashed with AttributeError on
`c['path'].replace(...)` before it could match the vdev by guid. This
broke pool.replace (and detach/offline/online/remove) for exactly the
disks that most need replacing: physically failed ones.
- find_disk_from_topology: match by guid first and only touch `path`
when it is set.
- detach/offline/online/remove: tolerate `path: None` in the
label_to_disk lookup and audit messages (fall back to the vdev guid,
matching zpool status display).
- ZPoolVdev API model: add nullable `path` field for the upcoming
truenas_pylibzfs change that exposes the raw ZPOOL_CONFIG_PATH
(which is preserved for missing devices). Defaults to null, so it is
compatible with both old and new pylibzfs.
- Add unit tests for find_disk_from_topology covering the
missing-disk (path=None) regression.
[AMDGPU] Add synthetic apertures and use them for barriers
Define what a synthetic aperture is, and adjust the barrier AS
to use this new system. This makes the barrier AS even safer to
use as now we can use all 32 bits of it without ever risking
hitting a valid address of any kind (LDS or outside LDS).
[RFC][AMDGPU] Add BARRIER address space
Add a new BARRIER address space that is used for global variables that are used to represent the barrier IDs in GFX12.5.
These barrier addresses just have values corresponding 1-1 to barrier IDs. They are still implemented on top of LDS, but the offsetting happens during an addrspacecast to generic, not whenever the barrier GV is used.
The motivation for this is to make the relation between LDS and barrier GVs explicit in the compiler. It does add a bit more complexity, but that complexity was already there, just hidden by pretending barrier GVs were actual LDS.
[clang][AMDGPU] Clean-up handling of named barrier type
- Allow the type in struct/classes in very limited circumstances. The goal is to enable creating trivial wrappers around the named barrier variable, but ensure we can't get into situations where things would get awkward. Currently this means we only allow the named barrier in RecordDecls with exactly 1 field, that have no base class, and are not inherited.
- Use a `amdgpu_barrier` LangAS for this type that currently maps to the local AS. This allows easy switching to the barrier AS in a future patch.
Make IP multicast router global variable MP safe.
Use a multicast router rwlock to protect the mrt_mrouter array.
Since we support one router per route table, also implement an API
version per router. Sockets in mrt_mrouter are reference counted.
Fix the name space a bit by using mrt_ prefix consistently. Keep
existing netlock and kernel lock until fine grained locking has
been finished.
OK claudio@
Repair last steps of portimport(1) ran from mystuff/
Obviously we can't update the freshly imported directory directly from
mystuff/, it has to be done from the real target directory. So trim
mystuff/ from the path before cd'ing there. This fixes the error below:
cvs server: failed to create lock directory for `/cvs' (/cvs/#cvs.lock): Permission denied
cvs server: failed to obtain dir lock in repository `/cvs'
cvs [server aborted]: read lock failed - giving up
While here revert rev 1.8 which didn't fix the underlying issue.
ok tb@
[libc++] Partially revert #208330 (#209928)
We found out that the new mechanism for detecting overriden functions
does not support Arm Pointer Authentication (PAuth). Addressing this
limitation is going to require changes to Clang. In the meantime, we
switched back to the old mechanism when PAuth is enabled.
[TableGen][RISCV] Generate pre/post-RA statistics for macro fusions (#209394)
Teach `MacroFusionPredicatorEmitter` to emit `Statistic` counters
recording how often each macro fusion is matched, and wire them
up for RISC-V.
This is based on the idea in #186499, generalized so counters are
generated automatically for any target using the emitter.
Because both the pre-RA and post-RA schedulers run MacroFusion,
a single counter would conflate the two. Counters are split into
pre-RA/post-RA variants, distinguished by the `NoVRegs` property,
addressing the double-counting concern from #186499:
```cpp
STATISTIC(NumTuneLDADDFusionPreRA, "Times TuneLDADDFusion Triggered (pre-ra)");
STATISTIC(NumTuneLDADDFusionPostRA, "Times TuneLDADDFusion Triggered (post-ra)");
...
if (SecondMI.getMF()->getProperties().hasNoVRegs())
[8 lines not shown]
[RFC][AMDGPU][InsertWaitcnts] Move `WaitcntBrackets` to a separate file
My previous stack of patches de-tangled quite a bit of InsertWaitcnt,
and now `WaitcntBrackets` can be moved into a separate file fairly
easily. I'm proposing this as a RFC. While I think this is a net
positive, I don't want to force this through if others feel it's unnecessary.
Implementation:
This pretty much moves `WaitcntBrackets` as-is, with a few changes:
- Instead of having a pointer to `SIInsertWaitcnts` for the "context"
there is now a "Info" class that `SIInsertWaitcnts` implements.
This enforces a small separation between the classes, not enough to
force a massive redesign, but enough that we can't just access the
entire state of `InsertWaitcnts` at will.
- Some unused/unnecessary functions were removed or made private.
- I reorganized the code a bit: moved all private functions together,
moved method implementations to the .cpp if they had more than 2 lines of code.
The goal is to keep things somewhat organized so it's easy to glance at the
[23 lines not shown]
