Age | Commit message (Collapse) | Author |
|
version for i386
more architectures and ctob() replacement is being worked on
prodded by and ok miod
|
|
ok pedro@ thib@
|
|
no binary change
|
|
"ap = v" comments in under 8 seconds, so it must be ok. and it compiles
too.
|
|
it's a good idea to use atomic.h operations on it. This mechanic
change updates all bit operations on p_flag to atomic_{set,clear}bits_int.
Only exception is that P_OWEUPC is set by MI code before calling
need_proftick and it's automatically cleared by ADDUPC. There's
no reason for MD handling of that flag since everyone handles it the
same way.
kettenis@ ok
|
|
|
|
should never be referenced outside the context of the process to which
this stack belongs unless we do the PHOLD/PRELE dance. Loads of code
doesn't follow the rules here. Instead of trying to track down all
offenders and fix this hairy situation, it makes much more sense
to not swap kernel stacks.
From art@, tested by many some time ago.
|
|
ok pedro@, miod@
|
|
|
|
out of procfs and gets a ptrace request PT_{READ,WRITE}_{I,D} as argument;
also procfs_checkioperm() becomes process_checkioperm().
From art@ some time ago; ok kettenis@ pedro@
|
|
of panics and bugfixes. Access curproc directly, do not expect a process
pointer as an argument. Should fix many "process context required" bugs.
Incentive and okay millert@, okay marc@. Various testing, thanks.
|
|
the protection of the memory mapping we're doing I/O on, or if we want to
leave them as they are. This should only be necessary for breakpoint
insertion in code, so we'll only use it for ptrace requests.
Initially from art@ after discussion with kettenis@ millert@ and I,
tested by many.
|
|
one case fixed here).
miod@ "appears to be harmless"
markus@ ok
|
|
|
|
everyone for the prompt review and ok of this work ;-) Yeah, that includes me
too, or maybe especially me. I am sorry.
Change the sched_lock to a mutex. This fixes, among other things, the infamous
"telnet localhost &" problem. The real bug in that case was that the sched_lock
which is by design a non-recursive lock, was recursively acquired, and not
enough releases made us hold the lock in the idle loop, blocking scheduling
on the other processors. Some of the other processors would hold the biglock though,
which made it impossible for cpu 0 to enter the kernel... A nice deadlock.
Let me just say debugging this for days just to realize that it was all fixed
in an old diff noone ever ok'd was somewhat of an anti-climax.
This diff also changes splsched to be correct for all our architectures.
|
|
|
|
ok deraadt@, miod@
|
|
enough to allow us to call vgone() from procfs_inactive(). to avoid a
deadlock, check for VXLOCK as well, in case we were called from
vclean(). problem report from Sho Fujita, okay tedu@.
|
|
in generated object file. from Joris Vink.
|
|
encapsulating all such access into wall-defined functions
that makes sure locking is done as needed.
It also cleans up some uses of wall time vs. uptime some
places, but there is sure to be more of these needed as
well, particularily in MD code. Also, many current calls
to microtime() should probably be changed to getmicrotime(),
or to the {,get}microuptime() versions.
ok art@ deraadt@ aaron@ matthieu@ beck@ sturm@ millert@ others
"Oh, that is not your problem!" from miod@
|
|
|
|
and m68k.
ok drahn@, millert@
|
|
ok deraadt@ millert@
problem noticed by deprotect.com
|
|
|
|
|
|
now call the poll backend. With this change we implement greater
poll(2) functionality instead of emulating it via the select backend.
Adapted from NetBSD and including some changes from FreeBSD.
Tested by many, deraadt@ OK
|
|
argument. old cred only calls user suser_ucred. this will allow future
work to more flexibly implement the idea of a root process. looks like
something i saw in freebsd, but a little different.
use of suser_ucred vs suser in file system code should be looked at again,
for the moment semantics remain unchanged.
review and input from art@ testing and further review miod@
|
|
|
|
|
|
|
|
rescinded 22 July 1999. Proofed by myself and Theo.
|
|
|
|
|
|
is set). deraadt@ and tholo@ OK.
|
|
ok art@
|
|
These are the files that were ok:ed and tested.
|
|
- cache_lookup
move common code from various fs's here
always return with vnode and parent locked
adjust return codes
- PDIRUNLOCK - new flag set if lookup couldn't lock parent vnode
- kernfs and procfs
lock vnode in get_root
don't unlock (again) in kernfs_freevp
fix memory leak in procfs
From tedu@stanford.edu
deraadt@ and various other ok
|
|
so that this compiles with option DIAGNOSTIC; fixes PR #2528
ok fgsch@
|
|
|
|
your kernel configuration file.
By default, GENERIC will enable this.
When PTRACE is not enabled, several ptrace-like features of the procfs
filesystem will be disabled as well (namely, the ability to read and write
any process' registers, as well as attching, single stepping and detaching
to/from processes).
This should help paranoid people build better sandboxens, and us to build
smaller ramdisks.
|
|
They still stay in MD code for backwards compatibility, but a check in
ptrace.h checks if they are defined.
Note - the same thing will be done with PT_{GET,SET}FPREGS once vax implements
them and with PT_STEP when it's implemented by sparc, sparc64 and alpha.
|
|
|
|
|
|
and procfs (and possibly more places in the future) and simply refuse to
fiddle with the execing process. This is an ugly hack, but this far we
haven't been successful in creating a race-free exec.
|
|
the filesystem if we're allowed to mmap the file.
|
|
|
|
|
|
(Look ma, I might have broken the tree)
|
|
|
|
|