ports.cgi: enable new responsive design
Implement and enable new design for ports.cgi, based on c9c518d9db
Also, move the submit button next to the input field and the select boxes
a row below. Looks better for some mobile devices (e.g. Android) which
cannot detect a submit by the enter key.
Reviewed by: ziaee
snd_hdsp*: malloc(9) with M_WAITOK
Perform the allocations outside the lock section so that we can use
M_WAITOK. Holding the lock here is actually not really necessary and we
could just as well remove it, but keep it for consistency.
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D59079
(cherry picked from commit b5c1ab6c8f2811278b801084713a6618f3b783d3)
snd_dummy: Bump primary channel count
Makes it easier to test scenarios involving more than 1 primary channels
per direction.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D59085
(cherry picked from commit 358fe149f591028945a8e5a51dff9121a2358c85)
sound: Prefer idle primary channels when allocating
dsp_chn_alloc() stopped at the first primary channel that was either
idle or already had vchans. Since the list is walked in order, the first
channel matched both conditions once it had been used, so every client
after the first was stacked onto it as a vchan and the remaining primary
channels were never allocated at all.
This is invisible on devices with a single primary channel, but not on
those which provide several. snd_emu10kx(4), for instance, registers
four primary channels for its front device, each able to run with its
own rate.
Look for an idle primary channel first, and only fall back to sharing
one that already has vchans when there is none left.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: markj
[3 lines not shown]
kern_linker: use __func__ correctly in diagnostics
__func__ is a variable not a string literal so pass it to printf. This
only manifest when KLD_DEBUG was defined so wasn't tested by an kernel
including LINT.
Reported by: Mark Millard <marklmi at yahoo.com>
Sponsored by: Innovate UK
textproc/uim: Update to 1.9.7
- Remove textproc/uim-gtk2 because the upstream dropped gtk2 support
- Add textproc/uim-gtk4
- Bump PORTREVISION of textproc/uim consumers
powerpc/radix: acquire the pmap lock in mmu_radix_extract()
mmu_radix_extract() walks the page tables without holding the pmap lock,
unlike its hash MMU counterpart moea64_extract(). A concurrent unmap can
free and recycle the page table page being walked, so the read returns
whatever now occupies that memory and the caller gets a physical address
that never existed.
That is how mmu_radix_sync_icache() came to hand a bogus address to
__syncicache() and panic the machine. Commit 1574ca1955f5 worked around
it by taking the pmap lock in mmu_radix_sync_icache(), but the machine
independent callers of pmap_extract() - vm_sync_icache(), proc_rwmem()
and the vslock() paths - remain exposed to the same failure.
Rename the existing body to mmu_radix_extract_locked(), which asserts the
lock, and make mmu_radix_extract() a thin wrapper that acquires it.
mmu_radix_sync_icache() already holds the pmap lock, so it calls the
locked variant directly and neither recurses nor reacquires the lock once
per page.
[7 lines not shown]
powerpc/radix: take the pmap lock in mmu_radix_sync_icache()
mmu_radix_sync_icache() walked the page tables with an unlocked
pmap_extract() and passed the result straight to PHYS_TO_DMAP(),
checking only that it was non-zero. Nothing keeps the mapping - or the
page table page holding it - alive across that window: if another thread
of the same process tears a mapping down concurrently, the page table
page can be freed and reused, so pmap_extract() reads arbitrary memory
and returns a bogus physical address. __syncicache() then dereferences
an unmapped direct map address and the kernel takes a data storage
interrupt:
fatal kernel trap:
exception = 0x300 (data storage interrupt)
virtual address = 0xc003317ca6022a00
dsisr = 0x40000000
srr0 = 0xc000000000f59460 (__syncicache)
lr = 0xc000000000f23588 (mmu_radix_sync_icache)
pid = 23878, comm = skyframe-evaluator-
[27 lines not shown]
powerpc/radix: acquire the pmap lock in mmu_radix_extract()
mmu_radix_extract() walks the page tables without holding the pmap lock,
unlike its hash MMU counterpart moea64_extract(). A concurrent unmap can
free and recycle the page table page being walked, so the read returns
whatever now occupies that memory and the caller gets a physical address
that never existed.
That is how mmu_radix_sync_icache() came to hand a bogus address to
__syncicache() and panic the machine. Commit 1574ca1955f5 worked around
it by taking the pmap lock in mmu_radix_sync_icache(), but the machine
independent callers of pmap_extract() - vm_sync_icache(), proc_rwmem()
and the vslock() paths - remain exposed to the same failure.
Rename the existing body to mmu_radix_extract_locked(), which asserts the
lock, and make mmu_radix_extract() a thin wrapper that acquires it.
mmu_radix_sync_icache() already holds the pmap lock, so it calls the
locked variant directly and neither recurses nor reacquires the lock once
per page.
[7 lines not shown]
