Pull up following revision(s) (requested by riastradh in ticket #1281):
sys/dev/pci/ld_virtio.c: revision 1.48 (patch)
ld at virtio: Guard virtio_dequeue by virtio_vq_is_enqueued.
After triggering the DMA operation, or any previous virtio_dequeue,
virtio_vq_is_enqueued issues the necessary bus_dmamap_sync for
virtio_dequeue to observe any potential (new) result.
Normally this happens inside virtio(4) (in virtio_vq_intr) between
interrupt delivery and calling the virtqueue's done callback. But
polling mode I/O operations (and dump operations) don't take that
path, so it is necessary to call virtio_vq_is_enqueued explicitly.
PR kern/60182: ld at virtio sometimes hangs up
Pull up following revision(s) (requested by wiz in ticket #1285):
lib/libc/citrus/modules/citrus_utf8.c: revision 1.19
Fix return value for some invalid UTF-8 byte sequences
Update the length definitions to honor RFC 3629 (from 2003):
o The octet values C0, C1, F5 to FF never appear.
Add a check that continuation bytes are valid when adding them to the
internal buffer so that an out-of-bytes error doesn't override the
"invalid bytes" error.
Fixes PR 60369 by Bruno Haible.
Pull up following revision(s) (requested by wiz in ticket #339):
lib/libc/citrus/modules/citrus_utf8.c: revision 1.19
Fix return value for some invalid UTF-8 byte sequences
Update the length definitions to honor RFC 3629 (from 2003):
o The octet values C0, C1, F5 to FF never appear.
Add a check that continuation bytes are valid when adding them to the
internal buffer so that an out-of-bytes error doesn't override the
"invalid bytes" error.
Fixes PR 60369 by Bruno Haible.
[SmallVector] Out-of-line the trivially-copyable push_back grow path (#206213)
In the approximately trivially-copyable specialization, push_back's grow
path does not early return. Both Clang and GCC likely keep `this` and
`Elt` live across the out-of-line `grow_pod` call, saving and restoring
them in the prologue/epilogue. Shrink wrapping can't sink it (the saved
values are used in the store block the fast path also reaches).
Move the grow-and-store into a noinline `growAndPushBack` helper and
tail call it. The fast path needs no callee-saved registers.
`push_back(int)` drops from 14 to 7 instructions on x86-64.
```
// void vec_pb_int(llvm::SmallVectorImpl<int>&v, int x){ v.push_back(x); }
mov eax, dword ptr [rdi + 8]
cmp eax, dword ptr [rdi + 12]
jae _ZN4llvm23SmallVectorTemplateBaseIiLb1EE15growAndPushBackEi # TAILCALL
mov rcx, qword ptr [rdi]
[12 lines not shown]
Pull up the following, requested by jdc in ticket #338:
external/mit/expat/dist/lib/xcsinc.c up to 1.1.1.1
external/mit/expat/dist/lib/fallthrough.h up to 1.1.1.1
external/mit/expat/dist/lib/memory_sanitizer.h up to 1.1.1.1
external/mit/expat/dist/memory-sanitizer-blacklist.txt delete
external/mit/expat/dist/CMake.README up to 1.1.1.10
external/mit/expat/dist/CMakeLists.txt up to 1.1.1.10
external/mit/expat/dist/Changes up to 1.1.1.11
external/mit/expat/dist/ConfigureChecks.cmake up to 1.1.1.6
external/mit/expat/dist/README.md up to 1.1.1.6
external/mit/expat/dist/configure.ac up to 1.1.1.9
external/mit/expat/dist/qa.sh up to 1.1.1.2
external/mit/expat/dist/doc/reference.html up to 1.1.1.10
external/mit/expat/dist/doc/xmlwf.xml up to 1.1.1.7
external/mit/expat/dist/lib/Makefile.am up to 1.1.1.5
external/mit/expat/dist/lib/expat.h up to 1.1.1.11
external/mit/expat/dist/lib/libexpat.def.cmake up to 1.1.1.3
external/mit/expat/dist/lib/random_arc4random_buf.c up to 1.1.1.2
[23 lines not shown]
[BOLT] Work around BSD sed's lack of in-place editing support (#206183)
BSD sed does not implement `-i` the same way as GNU sed. Use a
copy-and-replace approach instead of in-place editing to ensure
compatibility.
Pull up following revision(s) (requested by kre in ticket #334):
usr.bin/mail/fio.c: revision 1.46
usr.bin/mail/def.h: revision 1.29
usr.bin/mail/thread.c: revision 1.17
usr.bin/mail/thread.h: revision 1.4
PR bin/59635 - src/usr.bin/mail: fix post realloc() cleanup
This is a rather hackish solution, much better would be to abandon the
pointers altogether, and simply use message offsets (ints) into the array
to provide the relationships between messages.
Or abandon the message array (and the need for realloc() along with it)
and replace it with a list.
Both methods would achieve the aim of getting rid of the need to go and
massage the data to keep things correct when a realloc moves things around.
[9 lines not shown]
[gn] use `sources` instead of `inputs` for libc++ header copy action (#206263)
`sources` and `inputs` have the same semantics for GN action targets,
but the sync script can only handle `sources`.
Follow-up to cd98648925531663.
[libc++][NFC] Mark random_device::__padding_ as [[maybe_unused]] (#206248)
Instead of pushing and popping warnings we can just mark the offending
member as `[[maybe_unused]]`, improving compile times a bit and
simplifying the code.
Pull up following revision(s) (requested by riastradh in ticket #333):
sys/dev/pci/ld_virtio.c: revision 1.48
ld at virtio: Guard virtio_dequeue by virtio_vq_is_enqueued.
After triggering the DMA operation, or any previous virtio_dequeue,
virtio_vq_is_enqueued issues the necessary bus_dmamap_sync for
virtio_dequeue to observe any potential (new) result.
Normally this happens inside virtio(4) (in virtio_vq_intr) between
interrupt delivery and calling the virtqueue's done callback. But
polling mode I/O operations (and dump operations) don't take that
path, so it is necessary to call virtio_vq_is_enqueued explicitly.
PR kern/60182: ld at virtio sometimes hangs up
Pull up following revision(s) (requested by riastradh in ticket #1280):
sys/dev/pci/virtio.c: revision 1.85
virtio(4): Add missing BUS_DMASYNC_PREREAD operations.
And one missing BUS_DMASYNC_POSTREAD operation.
With this change, loads from vq->vq_used->flags (which occur
immediately after a transfer is submitted to test whether we need to
kick the host device) is separated by a PREREAD/POSTREAD cycle from
loads from vq->vq_used->idx (which occur when we think a transfer may
have completed, e.g. upon receiving an interrupt, to test whether it
has, in fact, completed).
Additionally, with this change, consecutive loads from
*vq->vq_avail_event are separated by a PREREAD/POSTREAD cycle.
Should fix virtio(4) issues on m68k and other related architectures
like mips and armv<7:
PR kern/60144: virtio(4) cache coherence issue
[152 lines not shown]
ctld: Normalize physical port names
Don't require ioctl port names to be fully expanded as this
contradicts the syntax documented in the ctl.conf(5). However, don't
require users to exactly guess when pp or vp can be omitted. Instead,
normalize all physical port names by parsing any port name with a pp
or vp value and reformatting them to a standardized format. This
format is also used when generating names for kernel-enumerated ports.
Reported by: Seth Hoffert <seth.hoffert at gmail.com>
Fixes: caef3c50ac06 ("ctld: Refactor ioctl port handling")
Sponsored by: Chelsio Communications
Pull up following revision(s) (requested by riastradh in ticket #332):
sys/dev/pci/virtio.c: revision 1.85
virtio(4): Add missing BUS_DMASYNC_PREREAD operations.
And one missing BUS_DMASYNC_POSTREAD operation.
With this change, loads from vq->vq_used->flags (which occur
immediately after a transfer is submitted to test whether we need to
kick the host device) is separated by a PREREAD/POSTREAD cycle from
loads from vq->vq_used->idx (which occur when we think a transfer may
have completed, e.g. upon receiving an interrupt, to test whether it
has, in fact, completed).
Additionally, with this change, consecutive loads from
*vq->vq_avail_event are separated by a PREREAD/POSTREAD cycle.
Should fix virtio(4) issues on m68k and other related architectures
like mips and armv<7:
PR kern/60144: virtio(4) cache coherence issue
[152 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1279):
sys/dev/pci/virtio_pci.c: revision 1.56
virtio(4): Allow virtio 0.9 BAR0 type to be memory rather than I/O.
This matches virtio>=1.0, and can't break working `hardware': any
existing virtio devices that worked must have reported I/O-type BAR0,
so they will continue to work; this will only enable previously
unusable virtio devices, reporting memory-type BAR0, to work.
Patch from Petri Koistinen.
PR kern/60247: virtio(4): legacy attach fails when BAR0 is MMIO
Pull up following revision(s) (requested by riastradh in ticket #331):
sys/dev/pci/virtio_pci.c: revision 1.56
virtio(4): Allow virtio 0.9 BAR0 type to be memory rather than I/O.
This matches virtio>=1.0, and can't break working `hardware': any
existing virtio devices that worked must have reported I/O-type BAR0,
so they will continue to work; this will only enable previously
unusable virtio devices, reporting memory-type BAR0, to work.
Patch from Petri Koistinen.
PR kern/60247: virtio(4): legacy attach fails when BAR0 is MMIO
