ufshci.4: Canonicalize SYNOPSIS, LOADER TUNABLES
+ Update SYNOPSIS to the new standard format
+ Rename CONFIGURATION to the usual LOADER TUNABLES
+ Adjust tunable markup for inclusion in the search index
+ Editorial nit: Unwind a parenthetical
MFC after: 3 days
ufoma: Describe better, short SYNOPSIS, tag SPDX
This driver is for NTT DoCoMo 3G cellular equiment, which afaict all
went offline six months ago. Tidy up the entry until we can remove it.
MFC after: 3 days
pfsync: when importing a state clear take the interface name into account
When one pfsync host clears states it informs its peers about this.
While processing such messages, in pfsync_in_clr() we failed to take the
interface name into account.
This meant that if one host cleared states on one interface the peers
would clear all states, not just those on the affected interface.
Actually check for the interface in pfsync_in_clr()
Sponsored by: Rubicon Communications, LLC ("Netgate")
lockf: Truncate the active lock list earlier in lf_purgelocks()
Otherwise vfs_report_lockf() can race with lf_purgelocks() while the
latter is freeing active lock entries without any locks held.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59768
udp: Let jail policy rewrite the dstaddr for v6 sendto()s
When performing an unconnected sendto() on a v6 UDP socket in a classic
jail, we were not applying the usual policy of replacing the loopback
addr with the jail's primary IP. Compare with, e.g., udp6_connect() or
the IPv4 udp_send(). Fix that.
Reported by: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li,
and Ke Xu from Tsinghua University using GLM-5.1 from Z.ai
Reviewed by: bz, glebius
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59772
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
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]
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]
vfs_lookup_cross_mount(): fix missing LK_CANRECURSE
This was a rather dumb miss on my part in commit 42442d7a6e.
LK_CANRECURSE is clearly needed in any case in which the covered vnode
is held exclusive across the call to VFS_ROOT(), regardless of whether
it was initially held exclusive or upgraded. The commit message for
that change also noted that unionfs lookup only worked without
LK_CANRECURSE due to a coincidence of the then-current unionfs
implementation. As it happens, said coincidence was recently removed
in commit b952606b4f ("unionfs_lock(): eliminate LK_CANRECURSE special-
case").
PR: 298201
Reported by: olivier
Fixes: 42442d7a6e "Generalize the VV_CROSSLOCK logic in
vfs_lookup"
Reviewed by: kib, markj, pho
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D59494
[2 lines not shown]
vfs_lookup_cross_mount(): fix missing LK_CANRECURSE
This was a rather dumb miss on my part in commit 42442d7a6e.
LK_CANRECURSE is clearly needed in any case in which the covered vnode
is held exclusive across the call to VFS_ROOT(), regardless of whether
it was initially held exclusive or upgraded. The commit message for
that change also noted that unionfs lookup only worked without
LK_CANRECURSE due to a coincidence of the then-current unionfs
implementation. As it happens, said coincidence was recently removed
in commit b952606b4f ("unionfs_lock(): eliminate LK_CANRECURSE special-
case").
PR: 298201
Reported by: olivier
Fixes: 42442d7a6e "Generalize the VV_CROSSLOCK logic in
vfs_lookup"
Reviewed by: kib, markj, pho
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D59494
[2 lines not shown]
nfsuserd.c: Fix handling where pw_name/gr_name differ from lookup name
When an NSS backend returns a canonical pw_name or gr_name that differs from
the lookup name supplied by the NFSv4 upcall, nfsuserd stores the successful
mapping in the kernel cache under the canonical name instead of the requested
name.
This causes the retry lookup performed by nfsv4_strtouid() or
nfsv4_strtogid() to miss the newly inserted cache entry, resulting in the
default UID/GID being returned although the NSS lookup itself succeeded.
PR: 296753
(cherry picked from commit 1771ab245c2341033f0cee3bd098c76888cf3515)
nfsuserd.c: Fix handling where pw_name/gr_name differ from lookup name
When an NSS backend returns a canonical pw_name or gr_name that differs from
the lookup name supplied by the NFSv4 upcall, nfsuserd stores the successful
mapping in the kernel cache under the canonical name instead of the requested
name.
This causes the retry lookup performed by nfsv4_strtouid() or
nfsv4_strtogid() to miss the newly inserted cache entry, resulting in the
default UID/GID being returned although the NSS lookup itself succeeded.
PR: 296753
(cherry picked from commit 1771ab245c2341033f0cee3bd098c76888cf3515)
dtrace/arm64: Fix copyout and copyoutstr
Calling dtrace_copy and dtrace_copystr with the kaddr and uaddr
arguments inversed does not work with PAN. Rename them
dtrace_copyin_pan and dtrace_copyinstr_pan, respectively, and
implement dtrace_copyout_pan and dtrace_copyoutstr_pan.
Avoid excessive faulting by checkin DTrace's CPU flags. Implement the
trick from OpenSolaris/Illumos of only checking the flags when
crossing into a new page, altough more effectively by examining the
vaddr instead of the count.
Reviewed by: markj
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D59449
add nprice to committers-src
Approved by: adrian (mentor)
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D59860
Signed-off-by: Nick Price <nprice at FreeBSD.org>
hastd: Use fixed-length protocol names
All communication between hastd nodes and internally between hastd and
its worker children passes through the same pair of send / receive
functions. The receive function uses recv(2) with the MSG_WAITALL flag,
which in theory means we should never get a short read. However, when
handing off a socket to a worker child, we also pass a variable-length
string identifying the type of socket we're passing, and reading this
string relies on a short read. This used to work because the arrival of
the descriptor would interrupt the recv(2) call, but this bug was fixed
when the AF_UNIX code was rewritten a while ago and hastd has been
broken ever since.
Fixing the length of the protocol name to four characters including the
terminating null solves the short-read bug by never requiring a short
read (nothing else in hastd requires one).
Note that this issue appears to have been reported independently first
by Alessandro Sagratini in PR 292322 and then by Martin Vidovic in
[11 lines not shown]
hastd: Ensure nvpair padding is initialized
The proto-libnv implementation embedded in hastd pads names and values
out to the nearest multiple of eight bytes, but leaves the padding
uninitialized, leaking up to 14 bytes of recycled heap per pair in a
message.
While here, switch from bcopy() to memcpy().
MFC after: 3 days
Reviewed by: kevans, emaste
Differential Revision: https://reviews.freebsd.org/D59343
(cherry picked from commit 911bda7cffbf358c4e83ea05cfe980d429aff61c)
