sys/param.h: Welcome to 11.99.8, courtsey of struct proc reordering.
PR kern/60653: posix_spawn(3) causes incorrect stack base information
XXX kernel ABI revbump -- NOT FOR PULLUP
struct proc: Put p_stackbase in the [p_startcopy,p_endcopy) range.
It is inherited by the child because the child has exactly the same
memory layout as the parent.
Cleanup after:
PR kern/60653: posix_spawn(3) causes incorrect stack base information
XXX kernel ABI revbump -- NOT FOR PULLUP
fork(2), vfork(2): Copy the parent's stack base pointer to the child.
Don't just leak whatever random stack pointer some recycled struct
proc had!
TBD: Move p_stackbase in struct proc so this is covered by the memcpy
above, in a separate commit so we can pull this one up without any
change to the layout of struct proc.
PR kern/60653: posix_spawn(3) causes incorrect stack base information
execve(2): Set p_stackbase in execve_runproc, not execve_loadvm.
execve_loadvm must not have side effects on the running process for
two reasons:
1. If execve(2) fails, it has to be able to back out and return to
the calling process. For example, the shell will execute the
first of a series of candidate paths that works when it searches
$PATH, and if one fails, it has to be able to move on to try the
next.
2. The caller may be the _parent_ process -- this is the case when
we're in posix_spawn.
Instead, it must be set in execve_runproc, after we're committed to
the exec and can't back out -- and we're definitely operating on the
process that is executing a new image, not on its parent!
p_stackbase and its assignment in exec_setup_stack, a subroutine of
[18 lines not shown]
t_signal_and_sp: Link against libpthread unconditionally now.
Required by new test cases added for:
PR kern/60653: posix_spawn(3) causes incorrect stack base information
Test various methods of getting the process's stack base and size.
And test the effect of fork, vfork, failed execve, and posix_spawn on
them.
PR kern/60653: posix_spawn(3) causes incorrect stack base information
exec: Free struct exec_package::ep_emul_arg in more error paths.
We should really formalize the destruction path for these temporary
exec data structures; these error branches are all tangled messes of
spaghetti.
PR kern/60657: panic: kernel diagnostic assertion "epp->ep_emul_arg
== NULL" failed: file
"/home/riastradh/netbsd/current/src/sys/kern/kern_exec.c", line 535
Test case forthcoming (it would panic the testbed) as part of
PR kern/60653: posix_spawn(3) causes incorrect stack base information
which is how I stumbled upon this.
fdt_pinctrl: don't skip pinctrl entries
Per the DT-bindings, pinctrl-n is a list of phandles, so a phandle every four bytes. If pinctrl-cells is more than one, the current code skips some phandles in the list since it advances by 4*pinctrl-cells bytes per entry.
This part of the code should not need to touch pinctrl-cells at all. pinctrl-cells is only relevant for the pinmux entries *inside* the pin controller, not for pin controller consumers.
This fixes the spi pinctrls on the am18xx.
pinctrl_simple: support bit-per-mux
pinctrl-single,bit-per-mux is an alternate mode some devicetrees use.
This enables using pinctrl_simple on the TI am18xx.
Pull up following revision(s) (requested by andvar in ticket #445):
sys/arch/x86/x86/identcpu.c: revision 1.143
Temporarily disable SMAP for CPUVENDOR_IDT vendor CPUs (if available).
SMAP feature causes a supervisor page fault during boot on KX-7000 CPUs.
port-amd64/60641
Pull up following revision(s) (requested by andvar in ticket #1334):
sys/arch/x86/x86/identcpu.c: revision 1.142
usr.sbin/cpuctl/arch/i386.c: revision 1.149
Decode L2 cache associativity for VIA CPUs using the AMD cache lookup table for
the 0x80000006 CPUID function associativity value.
Use `cpuid leaf 4' to get cache parameters for Zhaoxin and late VIA CPU models.
VIA datasheets mention that associativity is stored as a decimal value. However,
in practice, it is encoded the AMD way and does not store the actual value.
Using the raw value leads to an incorrect CPU colors calculation, causing a
panic on KX-7000 (since the result is not a power of two) and incorrect CPU
colors values on other CPU models (e.g. as visible in `vmstat -s').
Decoding value using the AMD cache lookup table produces correct values in all
cases I have tested or verified using CPUID dumps available online.
[31 lines not shown]
Pull up following revision(s) (requested by andvar in ticket #444):
sys/arch/x86/x86/identcpu.c: revision 1.142
usr.sbin/cpuctl/arch/i386.c: revision 1.149
Decode L2 cache associativity for VIA CPUs using the AMD cache lookup table for
the 0x80000006 CPUID function associativity value.
Use `cpuid leaf 4' to get cache parameters for Zhaoxin and late VIA CPU models.
VIA datasheets mention that associativity is stored as a decimal value. However,
in practice, it is encoded the AMD way and does not store the actual value.
Using the raw value leads to an incorrect CPU colors calculation, causing a
panic on KX-7000 (since the result is not a power of two) and incorrect CPU
colors values on other CPU models (e.g. as visible in `vmstat -s').
Decoding value using the AMD cache lookup table produces correct values in all
cases I have tested or verified using CPUID dumps available online.
[31 lines not shown]
Pull up following revision(s) (requested by joe in ticket #443):
sys/dev/ic/bcmgenet.c: revision 1.25
PR kern/60592
properly move bits to ensure unicast bit and locally administered
bits were rightly set.
Stop reusing sc_frequency as the workqueue arg. In 11.99.3 or so,
doing that wasn't a problem, but now it appears to be trouble doing
that. Just provide a dedicated variable. The argument doesn't really
matter to this use case, but it can't be something used for something
else either.
Pull up following revision(s) (requested by kre in ticket #1330):
usr.bin/xinstall/xinstall.c: revision 1.131 (patch)
PR bin/58577 - install(1) -d issues
Fix issues where "install -d" (with no directory) simply
exit(0)s. That one is kind of marginal, installing nothing
when nothing is needed could be treated as OK, but the man
page does indicate in the SYNOPSIS that with -d, at least
one directory is needed (it says nothing at all about that
in the text).
Second, after creating a directory, if a later operation
(chown, chmod) fails, that is not success, a warning was
issued (good), a bad metalog was being created (bad).
That is clearly a bug (though probably doesn't happen
very often).
[29 lines not shown]
Pull up following revision(s) (requested by kre in ticket #1331):
lib/libc/locale/runetable.c: revision 1.30
lib/libc/locale/iswctype_mb.c: revision 1.15
PR lib/59067 (wctrans got error member)
Patches from the OP (ru_j217) and from RVP - see the PR
This looks to be just correcting what appear to be simple
errors in the code.
Pull up following revision(s) (requested by kre in ticket #1332):
external/mit/xorg/lib/driver.old.mk: revision 1.3
external/mit/xorg/lib/driver.mk: revision 1.10 (patch)
PR xsrc/59858 (locale fixes for xsrc)
From RVP - see the PR
Oversimplifying: this causes Mesa to use LC_NUMERIC=C when using
strtod() to parse stuff (ie: the radix char (decimal point) is '.',
regardless of the user's locale).
nfs: On reflection, just clamp the export_args buffer to 64 KiB.
Keep it simple, just make sure userland doesn't trigger contiguous
kva allocation of more than 64 KiB.
PR kern/60645: nfssvc(2): arithmetic overflow in input array sizing
mount(8) - add -W option (like df -W)
Add a -W option to mount, to show wedge names as labels (NAME=xyzzy)
instead of /dev/dkN (and if given twice, both forms), similar to the
-W option in df(1).
nfs: Work around missing VM_MIN/MAX_KERNEL_ADDRESS in rump.
Let's get the builds unbroken before making this perfect.
PR kern/60645: nfssvc(2): arithmetic overflow in input array sizing
Kernels ALL/i386 and ALL/amd64 warn "'ticket' may be used uninitialized"
at line 244, uvmfault_amapcopy(): "uvm_wait("fltamapcopy", ticket);".
Restructure to reflect the logic better and keep GCC quiet.
Ok: Taylor R Campbell
PR kern/58964: uvm: missing wakeup on uvmexp.free
PR kern/60029: panic: cpu0: softints stuck for 16 seconds
