| Age | Commit message (Collapse) | Author |
|---|
|
hold the kernel lock, but still need call one function that needs it.
Instead of grabbing the lock all over the place, move the locks into
the affected functions: trapsignal, scdebug*, ktrsyscall, ktrsysret,
systrace_redirect and ADDUPROF. In the cases we already hold the biglock
we'll just recurse.
kettenis@, beck@ ok
|
|
KERNEL_PROC_LOCK -> KERNEL_LOCK
KERNEL_PROC_UNLOCK -> KERNEL_UNLOCK
oga@ ok
|
|
problem has been tracked down. This fixes the sharing of the signal
handling state: shared bits go in sigacts, per-rthread bits goes in
struct proc.
ok deraadt@
|
|
The new world order of pmemrange makes this data completely redundant
(being dealt with by the pmemrange constraints instead). Remove all code
that messes with the freelist.
While touching every caller of uvm_page_physload() anyway, add the flags
argument to all callers (all but one is 0 and that one already used
PHYSLOAD_DEVICE) and remove the macro magic to allow callers to continue
without it.
Should shrink the code a bit, as well.
matthew@ pointed out some mistakes i'd made.
``freelist death, I like. Ok.' ariane@
`I agree with the general direction, go ahead and i'll fix any fallout
shortly'' miod@ (68k 88k and vax i could not check would build)
|
|
Doesn't matter much since C++ ABI used by GCC doesn't mangle variable
names; however technically is required by Section 7.5 of the C++ spec.
Discussed with/OK guenther@, matthew@.
|
|
|
|
change. It seems to have unexpected side effects, especially on MP systems,
and drahn@ disagrees with the way this change has been done and think there
is a better way to solve the original problem of msleep() fiddling with
mutex internals.
|
|
until they're zombies and then send them signals (for intr mounts). Until
that is untangled, the sigacts change is unsafe. sthen@ was the victim
for this one
|
|
be shared (p_sigignore, p_sigcatch, P_NOCLDSTOP, P_NOCLDWAIT) moves
to struct sigacts, wihle stuff that should be per rthread (ps_oldmask,
SAS_OLDMASK, ps_sigstk) moves to struct proc. Treat the coredumping
state bits (ps_sig, ps_code, ps_type, ps_sigval) as per-rthread
until our locking around coredumping is better.
Oh, and remove the old SunOS-compat ps_usertramp member.
"I like the sound of this" tedu@
|
|
update the comment block accordingly.
|
|
|
|
always gaining anything, and msleep() implementation depends upon mtx_leave()
invoking splx().
|
|
a vforked child behave correctly. Have the parent in a vfork()
wait on a (different) flag in *its* process instead of the child
to prevent a possible use-after-free. When ktracing the child
return from a fork, call it rfork if an rthread was created.
ok blambert@
|
|
Discussed and okay drahn@. Okay deraadt@.
|
|
Okay guenther@, millert@.
|
|
instead of assuming it is ``everything below the kernel image''.
|
|
- move pte validity checks from pmap_remove_pte() to its callers.
- when iterating over a segment, compute pte address once and increment it
in the loop, instead of recomputing it on every iteration.
|
|
different version on 88110, which does load allocate of
to-be-completely-overwritten cache lines.
|
|
entries, drop the count parameter to cmmu_tlb_inv(), and introduce
cmmu_tlb_inv_all() to drop all user tlb entries (to be used during context
switches).
|
|
(those play nasty games with the stack pointer).
|
|
|
|
lines and restore them after invalidating rounded-to-cacheline-boundary ranges.
|
|
since a large part of the structures and logic remains.
Since m88k has separate supervisor/user spaces, we can map physical memory 1:1
in supervisor space, and have the kernel virtual address space start from the
end of physical memory.
This allows us to switch to __HAVE_PMAP_DIRECT. And to get rid of the double
mapped sdt, since now their virtual and physical addresses will always match.
The upper bound of the kernel virtual memory space is now platform dependent,
until the code which relies upon some hardware devices being mapped 1:1 in
supervisor mode is updated to no longer require this (this is mainly a PITA on
luna88k, where onboard devices start at 0x40000000, leaving only 1GB of KVA at
the moment - still much better than the previous 512MB).
Tested on mvme88k only (187, 188, 197LE, 197DP). Other platforms ought to
work, aviion will be checked shortly and fixed if necessary. No known
OpenBSD/luna88k system in working condition at the moment.
|
|
- a writeback->writethrough downgrade only requires a cache writeback, not a
writeback and invalidate.
- apparently the 88200 does not behave correctly (i.e. according to its
documentation) when a given page is accessed with both writethrough and
writeback cacheability (even though the cache lines are physically indexed
and physically tagged), so make sure to force writeback of writeback pages
when they risk being reused as writethrough (hair_count -= MAXHAIR).
Better coherency in page table backing store cacheability: these need to be
cache invalidated on 88100+88200 (because of hardware update of modified and
used pte bits), and writethrough on 88110.
|
|
introduces new ones as well. Main highlights are:
- 88200 lines which got marked as unusable by the BUG selftests will not be
reenabled at CMMU initialization time.
- better granularity in the 88110/88410 routines, to operate on ranges closer
to the actual requested area, errata permitting.
|
|
used two commits from now.
|
|
of flush/sync/inval. No functional change.
|
|
88200 BATC entries, and don't bother trying to flip pte bits in that case.
|
|
|
|
completed; this used to be the case, but revision 1.25 of this file, close
to four years ago, changed this behaviour by mistake. The side effects of this
mishandling of the cache did not show up until the kernel memory allocation
strategy moved towards fast reuse of freed pages.
Took me a while to track this down, maybe I'm getting too old to write code,
I probably should write backdoors instead.
|
|
|
|
a physical address [more precisely, something suitable to pass to pmap_enter()'sphysical address argument].
This allows MI drivers to implement mmap() routines without having to know
about the pmap_phys_address() implementation and #ifdef obfuscation.
|
|
the one used by the firmware, which (at least on mvme88k) is at address zero.
This is unfortunate, since this means that NULL pointer dereferences in the
kernel are not caught, and writes cause havoc.
This behaviour was necessary to be able to use the PROM system call interface
during early bootstrap, without having to disassemble the VBR page and
update branches - which use pc-relative displacement - if we were to use
a different VBR address.
On mvme88k, change this and actually set up two VBR pages: one, over the PROM
page (except for the system call vectors), and another one in the kernel
image (which will be mapped read-only). We'll run with the PROM page until
the end of autoconf, and then switch to the kernel one, and unmap all the
PROM below it.
As a bonus, the final kernel page can use optimized data access fault
handlers, which do not have to check for faults caused by badaddr(), since
badaddr() is only used during device probe on buses which do not support
hotplug.
There are a few infrastructure collateral damage on aviion and luna88k, but
these ports do not change their behaviour yet.
|
|
may be invoked with an address under the kernel text and we're about to
stop having such pages always mapped.
|
|
statistics. This allows these mappings to be removed with pmap_kremove()
without messing with accounting.
|
|
for it. This makes the netisr a real C function which will help further
development. No noticable performance change on i386 and amd64.
With input from kettenis@ and miod@ additional OKs mikeb@ and henning@
|
|
|
|
``invalid opcode'' in kernel mode after being idle for a few hours, since
many months already. This panic does not make sense.
Recently, I've been able to gather enough samples and, looking at the
instructions surrounding the panic location, I have narrowed a pattern,
and I'll conveniently blame these panics upon a (to the best of my
knowledge) new genuine 88110 bug.
The exception handler will now recognize this situation and apply a large
hammer of workaround - probably not the best workaround that could be devised,
but it's short, easy to implement, and works 100% of the time so far. Besides,
since the machine is idle, who cares as long as it keeps running?
(the curious reader will find more information in the trap.c comments)
|
|
its better as a per arch MD define anyway. all default to MAXDSIZ as before.
|
|
implement them, and they are of questionable usefulness.
|
|
provides an inline version of it.
|
|
to complete matthew@'s commit of a few days ago, and drop __HAVE_CPU_MUTEX_LEVEL
define. With help from, and ok deraadt@.
|
|
|
|
it defines. In some cases, this means pulling in uvm.h or pcb.h
instead, but most of the inclusions were just noise. Tested on
alpha, amd64, armish, hppa, i386, macpcc, sgi, sparc64, and vax,
mostly by krw and naddy.
ok krw@
|
|
This is a leftover from a very old workaround for a very old and long gone
pmap_enter() bug.
|
|
on 88110 designs. Brings a ~8% speedup on GENERIC.MP on 197DP.
|
|
ok miod@
|
|
On AViiON systems with the 6:1 CMMU:CPU configuration, force cached
mappings to be writethrough - this probably hides a bug in the code, but
that's the only way so far to get such a system running stably.
|
|
|
|
|
