More per-cpu data work:
- curcpu() needs to evaluate to a globally-accessible pointer, not a
cpu-local pointer, so do what the sparc port does here - provide a
ci_self that always points to the global pointer, and use that in
curcpu(). cpu_number() and curlwp reference through the cpu-local
alias.
- Rename that alias from cpu_info_store to cpuinfo, again mirroring
what the sparc port does here.
- Add the CPU_INFO_FOREACH() infrastructure, lifted from alpha port.
- Make the temp VAs used by the pmap code + the vmmap temp VA per-cpu.
Pull up following revision(s) (requested by riastradh in ticket #578):
sys/dev/usb/usb_quirks.c: revision 1.109
sys/dev/usb/usbdevs: revision 1.829
sys/dev/usb/uts.c: revision 1.19
Add product id for ELAN touchscreen controller.
Part of PR/60883.
Add support for ALWAYSON quirk to uts(4).
Add quirk for ELAN touchscreens.
Addresses PR/60883.
Pull up following revision(s) (requested by riastradh in ticket #1420):
sys/external/bsd/drm2/dist/drm/nouveau/nouveau_fence.c: revision 1.18
nouveau(4): Fix return value of fence wait.
kpause(9) returns EAGAIN/EWOULDBLOCK when it times out, which is
perfectly normal and expected here with an internal one-tick timeout
which should just go through another loop iteration. This function
is expected to return the number of ticks left to wait when done, so
it reports timeout by returning zero, and is forbidden to fail with
EAGAIN/EWOULDBLOCK.
This is also forbidden to fail with EINTR -- on interruption it must
fail with the Linux ERESTARTSYS instead. So map EINTR to that too
while here.
PR kern/59772: i386 11.0_BETA system crash (Xorg nouveau ?)
Pull up following revision(s) (requested by riastradh in ticket #1419):
sys/arch/x86/x86/efi_machdep.c: revision 1.7
sys/arch/x86/x86/efi_machdep.c: revision 1.8
x86/efi: Bypass kASAN memcpy when copying the efi runtime.
Fixes crash at boot with `options KASAN' enabled on EFI systems.
We could try to find some way to exclude the EFI runtime mappings
from kASAN, e.g. by hacking kasan_md_unsupported. But there's a lot
of detailed exclusions to pass through to that (every entry in the
EFI memory map), and this is the only memcpy in the whole kernel that
all those details are likely to be applicable.
PR kern/60391: kernel panic in efi_init() with "options KASAN"
x86/efi_machdep.c: Nix extra blank line.
[2 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #576):
sys/arch/x86/x86/efi_machdep.c: revision 1.7
sys/arch/x86/x86/efi_machdep.c: revision 1.8
x86/efi: Bypass kASAN memcpy when copying the efi runtime.
Fixes crash at boot with `options KASAN' enabled on EFI systems.
We could try to find some way to exclude the EFI runtime mappings
from kASAN, e.g. by hacking kasan_md_unsupported. But there's a lot
of detailed exclusions to pass through to that (every entry in the
EFI memory map), and this is the only memcpy in the whole kernel that
all those details are likely to be applicable.
PR kern/60391: kernel panic in efi_init() with "options KASAN"
x86/efi_machdep.c: Nix extra blank line.
[2 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1418):
sys/kern/exec_elf.c: revision 1.108
sys/kern/exec_elf.c: revision 1.109
sys/sys/exec_elf.h: revision 1.187
sys/sys/exec_elf.h: revision 1.188
exec_elf: Ignore freedesktop.org dlopen ELF notes.
PR kern/60901: Unknown elf note type 1081871370
exec_elf: Nix diagnostic messages for all (unknown) fd.o notes.
Same as for unknown GNU notes. Shaves off a tiny bit of code in
non-DIAGNOSTIC builds, saves us some trouble when fd.o invariably
adds more metadata not relevant to execution semantics.
PR kern/60901: Unknown elf note type 1081871370
Pull up following revision(s) (requested by riastradh in ticket #575):
sys/kern/exec_elf.c: revision 1.108
sys/kern/exec_elf.c: revision 1.109
sys/sys/exec_elf.h: revision 1.187
sys/sys/exec_elf.h: revision 1.188
exec_elf: Ignore freedesktop.org dlopen ELF notes.
PR kern/60901: Unknown elf note type 1081871370
exec_elf: Nix diagnostic messages for all (unknown) fd.o notes.
Same as for unknown GNU notes. Shaves off a tiny bit of code in
non-DIAGNOSTIC builds, saves us some trouble when fd.o invariably
adds more metadata not relevant to execution semantics.
PR kern/60901: Unknown elf note type 1081871370
Pull up following revision(s) (requested by riastradh in ticket #1417):
sys/dev/i2c/i2c.c: revision 1.109
i2c(4): Avoid leaking kernel heap memory to userland.
PR kern/60913: iic(4): I2C_IOCTL_EXEC can copy out an uninitialised
buffer
Pull up following revision(s) (requested by riastradh in ticket #574):
sys/dev/i2c/i2c.c: revision 1.109
i2c(4): Avoid leaking kernel heap memory to userland.
PR kern/60913: iic(4): I2C_IOCTL_EXEC can copy out an uninitialised
buffer
Pull up following revision(s) (requested by riastradh in ticket #1416):
etc/rc.d/network: revision 1.86
PR misc/60836 - Be more careful with /etc/ifconfig.* cloner configs
Only config cloner interfaces when an /etc/ifconfig.${cloner}N file
exists, if N is completely numeric.
Pull up following revision(s) (requested by riastradh in ticket #573):
etc/rc.d/network: revision 1.86
PR misc/60836 - Be more careful with /etc/ifconfig.* cloner configs
Only config cloner interfaces when an /etc/ifconfig.${cloner}N file
exists, if N is completely numeric.
Pull up following revision(s) (requested by riastradh in ticket #1415):
sys/external/bsd/common/include/linux/rcupdate.h: revision 1.9
drm: Fix rcu_replace_pointer.
This Linux API macro takes an _lvalue_ expression for an object, not
a pointer to the object -- unlike, e.g., the atomic_load/store
functions. So we can't copy its value into a local variable (to
avoid duplicate macro argument expansion) and then assign the local
variable with rcu_assign_pointer because that will only modify the
local copy, not the caller's lvalue!
Rename the macro parameters to make this clearer so it doesn't trip
me up again next time I read this.
Probably fixes dozens of graphics problems on a generation of Intel
hardware. Derp!
PR kern/60980: rcu_replace_pointer() fails to update the original pointer
Pull up following revision(s) (requested by riastradh in ticket #572):
sys/external/bsd/common/include/linux/rcupdate.h: revision 1.9
drm: Fix rcu_replace_pointer.
This Linux API macro takes an _lvalue_ expression for an object, not
a pointer to the object -- unlike, e.g., the atomic_load/store
functions. So we can't copy its value into a local variable (to
avoid duplicate macro argument expansion) and then assign the local
variable with rcu_assign_pointer because that will only modify the
local copy, not the caller's lvalue!
Rename the macro parameters to make this clearer so it doesn't trip
me up again next time I read this.
Probably fixes dozens of graphics problems on a generation of Intel
hardware. Derp!
PR kern/60980: rcu_replace_pointer() fails to update the original pointer
Pull up following revision(s) (requested by riastradh in ticket #1414):
sys/external/bsd/drm2/linux/linux_ww_mutex.c: revision 1.18
linux ww_mutex: Nix another assertion that trips in sketchy path.
Under the premise (explained in the comment above) that it is
legitimate for the upstream Linux code to do ww_mutex_trylock on a
mutex already held by the current thread, we can't assert
mutex->wwm_state != WW_WANTOWN ||
mutex->wwm_u.ctx->wwx_owner != curlwp
any more than we can assert
mutex->wwm_state != WW_CTX ||
mutex->wwm_u.ctx->wwx_owner != curlwp
because if the latter condition is possible, then any concurrent
[7 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #571):
sys/external/bsd/drm2/linux/linux_ww_mutex.c: revision 1.18
linux ww_mutex: Nix another assertion that trips in sketchy path.
Under the premise (explained in the comment above) that it is
legitimate for the upstream Linux code to do ww_mutex_trylock on a
mutex already held by the current thread, we can't assert
mutex->wwm_state != WW_WANTOWN ||
mutex->wwm_u.ctx->wwx_owner != curlwp
any more than we can assert
mutex->wwm_state != WW_CTX ||
mutex->wwm_u.ctx->wwx_owner != curlwp
because if the latter condition is possible, then any concurrent
[7 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1413):
sys/external/bsd/drm2/dist/drm/i915/gem/i915_gem_pages.c: revision 1.8
i915: Fix null pointer deref in i915_gem_object_get_dma_address.
Matches the Linux code in the #else this way.
PR kern/60755: i915drmkms crashes on Intel Bay Trail GPU making the
machine rebooting
Pull up following revision(s) (requested by riastradh in ticket #570):
sys/external/bsd/drm2/dist/drm/i915/gem/i915_gem_pages.c: revision 1.8
i915: Fix null pointer deref in i915_gem_object_get_dma_address.
Matches the Linux code in the #else this way.
PR kern/60755: i915drmkms crashes on Intel Bay Trail GPU making the
machine rebooting
Pull up following revision(s) (requested by riastradh in ticket #1412):
sys/external/bsd/drm2/dist/drm/nouveau/nouveau_fence.c: revision 1.19
nouveau: Don't set dma fence error if already signaled.
This happens asynchronously on hardware error. Upstream Linux trips
WARN_ON in this case; our dma_fence_set_error trips KASSERT instead.
We could maybe switch dma_fence_set_error to use WARN_ON too but it's
probably better not to take this path anyway -- this assertion trips
on logic that is incoherent, if not outright wrong.
PR kern/58745: nouveau triggered assert in linux_dma_fence.c
Pull up following revision(s) (requested by riastradh in ticket #569):
sys/external/bsd/drm2/dist/drm/nouveau/nouveau_fence.c: revision 1.19
nouveau: Don't set dma fence error if already signaled.
This happens asynchronously on hardware error. Upstream Linux trips
WARN_ON in this case; our dma_fence_set_error trips KASSERT instead.
We could maybe switch dma_fence_set_error to use WARN_ON too but it's
probably better not to take this path anyway -- this assertion trips
on logic that is incoherent, if not outright wrong.
PR kern/58745: nouveau triggered assert in linux_dma_fence.c
Pull up following revision(s) (requested by riastradh in ticket #1411):
sys/external/bsd/drm2/dist/drm/i915/gt/intel_lrc.c: revision 1.10
sys/external/bsd/drm2/dist/drm/i915/gt/intel_lrc.c: revision 1.9
i915: Fix execlist submission register indexing.
PR port-amd64/58657: i915drmkms blank screen
i915: Fix execlist submission register indexing harder.
This time, with any luck, I transcribed the indexing correctly.
PR port-amd64/58657: i915drmkms blank screen
Pull up following revision(s) (requested by riastradh in ticket #568):
sys/external/bsd/drm2/dist/drm/i915/gt/intel_lrc.c: revision 1.10
sys/external/bsd/drm2/dist/drm/i915/gt/intel_lrc.c: revision 1.9
i915: Fix execlist submission register indexing.
PR port-amd64/58657: i915drmkms blank screen
i915: Fix execlist submission register indexing harder.
This time, with any luck, I transcribed the indexing correctly.
PR port-amd64/58657: i915drmkms blank screen
Pull up following revision(s) (requested by riastradh in ticket #1410):
sys/kern/kern_exec.c: revision 1.536
sys/kern/kern_fork.c: revision 1.237
sys/rump/librump/rumpkern/lwproc.c: revision 1.60
fork, posix_spawn: Avoid race with setsid/setpgid.
PR kern/60962: fork and spawn read p_pgrp without proc_lock
rump: Copy struct proc::p_pgrp explicitly
Now that it's not in p_startcopy/endcopy, the memcpy isn't enough.
Should fix the thousands of test failures I caused by moving p_pgrp
out of the p_startcopy/endcopy range!
PR kern/60962: fork and spawn read p_pgrp without proc_lock
