| Age | Commit message (Collapse) | Author |
|---|
|
This flag caused amaps to be allocated with additional spare slots, to
make extending them cheaper. However, the kernel never extends amaps,
so allocating spare slots is pointless. Also UVM_FLAG_AMAPPAD only
has an effect in combination with UVM_FLAG_OVERLAY. The only function
that used both flags was sys_obreak, but that function had the use of
UVM_FLAG_OVERLAY removed recently.
While there, kill the unused prototypes amap_flags and amap_refs.
They're defined as macros already.
ok mlarkin@ kettenis@ mpi@
|
|
Found by LLVM/Clang Static Analyzer.
ok mpi@ stefan@
|
|
In the code, this function is called when vm_map_entries are merged.
However, only kernel map entries are merged, and these do not use amaps.
Therefore amap_extend() is never called at runtime.
ok millert@, KASSERT suggestion and ok mpi@
|
|
torture tested on amd64, i386 and macppc
ok beck mpi stefan
"the change looks right" deraadt
|
|
The compiler is also smart enough to recognize that this is redundant.
The resulting code on amd64 is basically equivalent (slightly different
register allocation and instruction scheduling).
ok mpi@ deraadt@
|
|
Started by diff from Mical Mazurek.
|
|
This avoids wasting kernel memory if the user process does not make
use of the allocated memory.
Testing by sthen@ and tobiasu@, thanks!
ok deraadt@
|
|
This saves some memory compared to using malloc, because there's
no roundup to the next bucket size. And it reduces kmem pressure
at least for some architectures (e.g. amd64).
Testing by sthen@ and tobiasu@, thanks!
ok sthen@ deraadt@
|
|
|
|
ok mpi@ millert@
|
|
ok mpi@ visa@
|
|
When only one thread can access a map, there's no need
to lock it. Tweak the assertion instead of appeasing it
by acquiring a lock when it's not necessary.
ok kettenis@
|
|
Remove machdep.userldt sysctl.
Remove i386_[gs]et_ldt syscall stub from libi386.
Remove i386_[gs]et_ldt regression test.
ok mlarkin@ millert@ guenther@
|
|
from ray@, ok jmc@
|
|
|
|
map. This removes the (hopefully) last case in which pool_put() might try
to grab the kernel lock for interrupt-safe pools. Note that pools that are
created with the PR_WAITOK flag will still grab the kernel lock.
ok mpi@, tedu@
|
|
it relies upon the fpageq lock for data consistency and
sleep/wakeup interlocking.
Therefore, code which modifies page zeroing thread data
or performs a wakeup of the thread must also hold the
fpageq lock.
Fix an instance where this was not the case.
ok kettenis@
diff --git a/sys/uvm/uvm_pmemrange.c b/sys/uvm/uvm_pmemrange.c
|
|
ok tedu@
|
|
|
|
associated mistake in the uvm manpage.
Suggested by and ok tedu@
|
|
discussed with miod, deraadt, and guenther.
|
|
- rename _check function without suffix: a "pledge" function called from
anywhere is a "check" function.
- makes pledge_fail call the responsability to the _check function. remove it
from caller.
- make proper use of (potential) returned error of _check() functions.
- adds pledge_kill() and pledge_protexec()
with and OK deraadt@
|
|
uvm_page_init() (causing uvmexp.npages to be sligthly wrong if
pmap_steal_memory() has been used) and uvm_page_physload().
ok guenther@ kettenis@ visa@ beck@
|
|
ps-style programs (there are quite a few in the tree, including tmux).
"vminfo" exposes a bit more system operation information, which many
observation programs want (such as top). settime allows setting the system
time, and will be used to pledge-protect the last ntpd process.
|
|
strict than anticipated. It allows a programmer to pledge/promise/covenant
that their program will operate within an easily defined subset of the
Unix environment, or it pays the price.
|
|
mtx_enter() and mtx_leave() operations. Not 100% this won't blow up but
there is only one way to find out, and we need this to make progress on
further unlocking uvm.
prodded by deraadt@
|
|
or pager code. We may end up here without holding the kernel lock from
uvm_unmap().
"ja ja" tedu@
|
|
- by default, a tamed-program don't have the possibility to use PROT_EXEC for
mmap(2) or mprotect(2)
- for that, use the request "prot_exec" (that could be dropped later)
initial idea from deraadt@ and kettenis@
"make complete sense" beck@
ok deraadt@
|
|
will perform the unmap as necessary, holding the vm lock.
reminded by kettenis
|
|
this pulls all the relevant operations under the same map locking, and
relieves calling code from responsibility.
ok kettenis matthew
|
|
crashes seen by sthen@ on i386.
ok visa@, guenther@, tedu@
|
|
together the unmap and map portions of a fixed mmap. make this explicit
by pulling the lock up higher. in preparation for unlocking the syscall.
there's still (always has been) a race where if the unmap sleeps, another
mmap may see partial results because the map lock isn't held througout.
another problem, another day.
|
|
data, only new
|
|
consistency with PQ_AOBJ.
Input kettenis@, ok beck@
|
|
remainder of that commit was backed out. However,clearing the PQ_AOBJ bit
here is definitely wrong.
Our pagedaemon uses two separate lists to keep track of inactive
pages. It uses PQ_SWAPBACKED, which really is both PQ_ANON and
PQ_AOBJ to keep track of which inactive queue a page is sitting on.
So if you twiddle PQ_AOBJ (or PQ_ANON) for an inactive page, a
subsequent uvm_pagefree(9) will remove the page from the wrong queue!
This usually goes unnoticed, but if the page happens to be the last
one on the queue, the queues get corrupted. The damage quickly
spreads to the free page queues and almost certainly results in the
uvm_pmr_size_RB_REMOVE_COLOR() faults that people have seen
sporadically since the spring of this year.
ok visa@, beck@, krw@, guenther@
|
|
necessary
ok deraadt@ jsing@
|
|
normal maps.
ok beck@, miod@, guenther@
|
|
set). Since we cannot sleep in that case, use a mutex instead of an rwlock.
This is ok as the more complex code paths in the uvm code are not entered
for interrupt-safe maps as paging isn't allowed in those maps.
ok tedu@
|
|
#ifndef pmap_resident_count code paths.
|
|
|
|
|
|
|
|
ok mpi@, visa@
|
|
|
|
ok kettenis@
|
|
no way.
|
|
the page loaning code is already in the Attic.
ok kettenis@, beck@
|
|
an exact match.
ok kettenis@
|
|
ok kettenis@
|
|
compiler will warn.
|
