__attribute__((constructor)) to determine which rump kernel components
and kernel modules are linked into the rump kernel. If not defined
(default), use the regular approach with link sets.
This option is aimed to fix problems with toolchains where using link
sets is not possible because the linker does not generate the requisite
__start/__stop symbols for the link set sections (e.g. GNU gold, OS X, ...).
pmap_{zero,copy}_page cache alias handing. The check previously used
PG_MD_UNCACHED_P, where it now uses PG_MD_CACHED_P, when considering if
a cache invalidation is required.
Additionally flush the cache for the uarea va to avoid potential (future)
cache aliases in cpu_uarea_free when handing pages back to uvm for later
use.
ok matt@
Hopefully this addresses the instability reported in the following PRs:
PR/44900 - R5000/Rm5200 mips ports are broken
PR/46170 - NetBSD/cobalt 6.0_BETA does not boot
PR/46890 - upcoming NetBSD 6.0 release is very unstable / unusable on cobalt qube 2
PR/48628 - cobalt and hpcmips ports are dead
coredump_buildname() copies 'pattern' into 'name', and handles special
characters such as "%n". "%n", if present, will be replaced by p->p_comm.
error = coredump_buildname(p, name, pattern, MAXPATHLEN);
This function handles overflows, and returns an error when 'name' becomes
larger than MAXPATHLEN. However, when coredump() calls it, 'name' is used
before the error check, with:
lastslash = strrchr(name, '/');
'name' is not guaranteed to be NUL-terminated, because of the *d = *s in
coredump_buildname(). This strrchr will read a string which is not NUL-
terminated (ie. until finding a '\0' in memory).
'pattern' can't be higher than MAXPATHLEN. A user can fill it in via a
PT_DUMPCORE ptrace call, given the input is not longer than MAXPATHLEN.
Since the 2-bytes-sized "%n"s will be replaced by p->p_comm (which is
user-settable, like a 10-bytes-sized "0123456789"), 'name' can become
longer than 'pattern' (and thus longer than MAXPATHLEN). Some 'a's at the
end of the buffer will make sure 'name' is not NUL-terminated.
pattern: "%n%n%naaaaaaaaaaaaaaaaaaaaaaaaaaaa\0"
| | | |||||||||||||||||||||||||||||
-> name: "012345678901234567890123456789aaaaa" [no \0]
| | | |||||MAXPATHLEN
Fix it by checking 'error' before calling strrchr.
updated. pmap_free_l2_bucket already deals with the kernel pmap properly.
ok matt@
Should fix the
panic: kernel debugging assertion "mappings <= l2b->l2b_occupancy" failed:
file "/usr/src/sys/arch/arm/arm32/pmap.c", line 3838
problem reported on port-arm by Joachim Thiemann
