Pull up following revision(s) (requested by riastradh in ticket #1389):
common/lib/libc/arch/x86_64/string/memchr.S: revision 1.7
common/lib/libc/arch/x86_64/string/memchr.S: revision 1.8
tests/lib/libc/string/t_memchr.c: revision 1.4
tests/lib/libc/string/t_memchr.c: revision 1.5
tests/lib/libc/string/t_memchr.c: revision 1.6
tests/lib/libc/string/t_memchr.c: revision 1.7
(all via patch)
PR lib/60744 demonstrate memchr(3) is busticated with a test
PR lib/60744 at least this test passes on i386
t_memchr: Sprinkle a few more NUL byte tests.
PR lib/60744: memchr(3) is busticated
[8 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #544):
tests/lib/libc/string/Makefile: revision 1.16
common/lib/libc/arch/x86_64/string/memchr.S: revision 1.7
common/lib/libc/arch/x86_64/string/memchr.S: revision 1.8
tests/lib/libc/string/t_memchr.c: revision 1.4
tests/lib/libc/string/t_memchr.c: revision 1.5
tests/lib/libc/string/t_memchr.c: revision 1.6
tests/lib/libc/string/t_memchr.c: revision 1.7
PR lib/60744 demonstrate memchr(3) is busticated with a test
PR lib/60744 at least this test passes on i386
t_memchr: Sprinkle a few more NUL byte tests.
PR lib/60744: memchr(3) is busticated
[8 lines not shown]
Pull up the following requested by riastradh in ticket #1386:
sys/compat/linux32/arch/aarch64/linux32_exec_machdep.c 1.3 (patch)
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
[22 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1387):
sys/net/if.c: revision 1.539
ioctl(SIOCSIFGENERIC): Check for network interface setpriv.
PR kern/60745: doifioctl: priv check for SIOCSIFGENERIC
Pull up following revision(s) (requested by riastradh in ticket #542):
sys/net/if.c: revision 1.539
ioctl(SIOCSIFGENERIC): Check for network interface setpriv.
PR kern/60745: doifioctl: priv check for SIOCSIFGENERIC
Pull up following revision(s) (requested by riastradh in ticket #541):
sys/compat/netbsd32/netbsd32_signal.c: revision 1.57
sys/kern/kern_fork.c: revision 1.235
sys/kern/exec_subr.c: revision 1.93 (via patch)
sys/kern/kern_exec.c: revision 1.534 (via patch)
sys/kern/kern_exec.c: revision 1.535 (via patch)
sys/kern/exec_script.c: revision 1.86 (via patch)
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
[78 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1385):
sys/kern/sys_process_lwpstatus.c: revision 1.6
sys/kern/sys_process_lwpstatus.c: revision 1.7
sys/kern/sys_process_lwpstatus.c: revision 1.8
sys/arch/x86/include/dbregs.h: revision 1.9
sys/kern/sys_process_lwpstatus.c: revision 1.9
sys/sys/ptrace.h: revision 1.78
sys/arch/x86/x86/dbregs.c: revision 1.16
sys/kern/sys_process_lwpstatus.c: revision 1.10
sys/arch/i386/i386/process_machdep.c: revision 1.98
sys/compat/netbsd32/netbsd32_ptrace.c: revision 1.10
sys/compat/netbsd32/netbsd32_ptrace.c: revision 1.11
sys/arch/amd64/amd64/process_machdep.c: revision 1.51
ptrace/procfs: Take lwp lock around process_read/write_(fp)regs(32).
And verify that the lwp is in LSSTOP state before trying to read.
[62 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #540):
sys/kern/sys_process_lwpstatus.c: revision 1.6
sys/kern/sys_process_lwpstatus.c: revision 1.7
sys/kern/sys_process_lwpstatus.c: revision 1.8
sys/arch/x86/include/dbregs.h: revision 1.9
sys/kern/sys_process_lwpstatus.c: revision 1.9
sys/sys/ptrace.h: revision 1.78
sys/arch/x86/x86/dbregs.c: revision 1.16
sys/kern/sys_process_lwpstatus.c: revision 1.10
sys/arch/i386/i386/process_machdep.c: revision 1.98
sys/compat/netbsd32/netbsd32_ptrace.c: revision 1.10
sys/compat/netbsd32/netbsd32_ptrace.c: revision 1.11
sys/arch/amd64/amd64/process_machdep.c: revision 1.51
ptrace/procfs: Take lwp lock around process_read/write_(fp)regs(32).
And verify that the lwp is in LSSTOP state before trying to read.
[62 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #539):
sys/arch/amd64/amd64/machdep.c: revision 1.381
amd64: Make XSAVE area overlap mcontext_t on signal delivery.
Additionally, if the stack pointer is already such that pushing a
struct sigframe_siginfo would make it congruent to -8 modulo the
stack alignment, as the signal handler expects (-8 for the return
address on an aligned stack frame), don't re-align it again -- it's
just fine as is.
Previously, for NetBSD 11.0, we would copy out an XSAVE area
separately from ucontext_t, and copy out the FXSAVE content twice in
two different places on the stack -- one in the ucontext_t for
compatibility so older applications can still read x87/SSE registers,
and one in the XSAVE area:
+-----------------------+ | (other XSAVE stuff) | |
[88 lines not shown]
Be more conservative with pool and freelist sizes and address potential deadlocks discovered while working on PR kern/60396.
Note that with this change we track the total amount of memory allocated to
both reserved buffers and pools on a per-array basis, and constrain
"openings" to keep it under control on small-memory machines.
1) Per suggestion from oster@, rename the "emergency" freelists that are now
used before dynamic allocation to "reserved" freelists.
2) Eliminate static pool sizes and compute dynamically instead. For now,
most are larger to avoid potential deadlocks discussed below. With
some restructuring of the I/O dispatch model they can probably get smaller.
3) Address an M_WAITOK allocation with PSS_MUTEX held in "forced"
reconstruction. It appears this could deadlock rf_RaidIOThread
and the recon thread. Added another small set of emergency
buffers to cover this case.
4) Reorganize rf_Configure to initialize pools _after_ disk,
[35 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1384):
external/bsd/file/dist/src/fsmagic.c: revision 1.19
external/bsd/file/include/config.h: revision 1.22
tests/dev/fss/t_fss.sh: revision 1.8
lib/libutil/stat_flags.c: revision 1.4
lib/libutil/stat_flags.c: revision 1.5
external/bsd/file/dist/configure.ac: revision 1.24
(all via patch)
string_to_flags(3): Support `snap' (SF_SNAPSHOT).
PR bin/60380: find(1) can't find snapshots
string_to_flags(3): Put `snap' under #ifdef SF_SNAPSHOT.
Same as in flags_to_string(3). Not really sure why, but let's keep it
consistent so there's only one question to ponder and not two.
[13 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #538):
external/bsd/file/dist/src/fsmagic.c: revision 1.19
external/bsd/file/include/config.h: revision 1.22
tests/dev/fss/t_fss.sh: revision 1.8
lib/libutil/stat_flags.c: revision 1.4
lib/libutil/stat_flags.c: revision 1.5
external/bsd/file/dist/configure.ac: revision 1.24
(all via patch)
string_to_flags(3): Support `snap' (SF_SNAPSHOT).
PR bin/60380: find(1) can't find snapshots
string_to_flags(3): Put `snap' under #ifdef SF_SNAPSHOT.
Same as in flags_to_string(3). Not really sure why, but let's keep it
consistent so there's only one question to ponder and not two.
[13 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1380):
lib/libc/gen/pthread_atfork.c: revision 1.19
PR/59112: Martin Husemann: switch to using mmap instead of malloc
Pull up following revision(s) (requested by riastradh in ticket #1379):
lib/libc/arch/arm/misc/arm_initfini.c: revision 1.8
lib/libc/arch/arm/misc/arm_initfini.c: revision 1.9
lib/libc/arch/arm/misc/arm_initfini.c: revision 1.10
PR/59063: Martin Husemann: Avoid using malloc through sysctlbyname by doing
the sysctl name to mib translation directly. Thanks martin@ for testing!
use the latest version that does not abort on error.
don't abort, just fail.
Pull up following revision(s) (requested by riastradh in ticket #1378):
external/bsd/nvi/dist/regex/regcomp.c: revision 1.9
PR/59103: RVP: Search of non-ASCII chars. broken when `:set extended' is set
Pull up following revision(s) (requested by riastradh in ticket #1377):
share/man/man9/module.9: revision 1.55
PR 59102: fix signature of module callback function.
revert ohci 1.330:
---
use PR_ZERO on on pool allcoated memory and get rid of memset.
currently, xfer is zeroed using the wrong size.
remove it and simplify code.
reviewed by christos@
---
Taylor pointed out that pool_cache*() does not document or honour
PR_ZERO, so this actually no longer is returning zeroed ohci_xfer
structures. it also did not have the "wrong size", but that is an
understandable mistake -- the cost assignes to "struct usb_xfer *",
but is really a "struct ohci_xfer", which is usb_xfer + more, so
while it appears to be memset()ing beyond the buffer, it isn't.
wrt pool_cache and PR_ZERO, there's a strange conflict between the
[11 lines not shown]
