| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
effectively been a no-op for quite some time now,
without promise for future usage.
ok pedro@
Testing by krw@ (earlier diff)
and Johan Mson Lindman (tybollt@solace.miun.se)
|
|
|
|
devices with sectorsizes other than 512. e.g. cd's. Fixes PR #5235
from Paul Stoeber with a slightly tweaked diff. NetBSD did the same
with their r1.59 in 2001, closing their PR#3261 and PR#14026.
tweak suggestions and ok pedro@
|
|
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@
|
|
the only use was in an #if notyet chunk since '97.
ok miod@
'no objections' pedro@
|
|
|
|
from krw@ and toby@, subliminal prodding from dlg@, okay deraadt@.
|
|
|
|
block devices where ioctl request is zero and data is B_TAPE, which no sane
userland program uses those days.
General disgust and ok deraadt@ millert@ weingart@
|
|
Discussed with and ok deraadt@ millert@
|
|
a write that will globber the whole buffer, and it's not in cache, do
not bother reading it in. That's wrong, since the user may be trying to
write beyond the disk extent, in which case we definitely want to return
an error, rather than returning saying the write was okay, and failing
later on at an 'uncatched' biodone(). Okay tedu@.
|
|
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.
|
|
double-lock the vnode if we're coming from vclean()
|
|
|
|
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@.
|
|
which is not possible here. Problem found and fixed by form@.
ok millert@ fgsch@ pedro@
|
|
|
|
|
|
in generated object file. from Joris Vink.
|
|
Problem found by Christer Oberg. OK henning@, deraadt@
|
|
|
|
flushing loop, otherwise we could hard-lock the machine when unmounting
an union filesystem
ok tedu@
|
|
|
|
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@
|
|
|
|
using CMSG_ALIGN was wrong, userland fires in data not so aligned.
if fd_getfile returns NULL, don't try to close the fd, since it's not there.
|
|
|
|
hackers@ ok
|
|
|
|
|
|
and m68k.
ok drahn@, millert@
|
|
|
|
|
|
O_NONBLOCK set and there are no readers. Before returning ENXIO
fifo_open calls VOP_CLOSE (and hence fifo_close). However, since
fi_writers has not yet been incremented, when fifo_close decements
fi_writers it is one too few. This could cause qmail processes
to spin, consuming all the CPU.
Noticed by avsm@ and henning@, test case provided by claudio@, Ok pedro@
|
|
|
|
ok deraadt@ millert@
problem noticed by deprotect.com
|
|
|
|
|
