this bug was introduced in the plan9 port, and since i_sound.c compiles with
no warning, it was never noticed. in effect, the statement between the
unterminated comment and the next is ignored. channelids[] is used in addsfx()
to avoid re-adding certain sounds if they are already playing. one of those is
sfx_sawful, and because of this bug, it is added again each tic during which
the player fires the chainsaw, rather than reset every tic.
compare firing the chainsaw continuously with and without the patch (without
hitting an enemy).
theres code that assumes one can dereference a char[] buffer on the stack
as a long (ghostscript gxblend.c), so make sure all automatics on the stack
are word aligned. this is not strictrly neccesary, but avoids some
trouble with unportable code.
buffers which still have requests queued on them are not free!
we cannot chanedev() a buffer while it has still requests queued on it
and we canot just queue our request (having different address) on the
buffer while there are other requests before it, otherwise we would
create artificial block dependency that can cause deadlock.
it is possible for another getbuf() on buffer b to come in
before undelayreq() calls givebuf() on a buffer again. then
givebuf() would find b already busy and abort().
instead, we now handle what getbuf() did in givebuf() and
consider the Buf* argument to givebuf() as a hint only for
the case when we have to actually flush/read a block from
disk.
when wunlock() was used by threads running within the same proc,
the wunlock() can deadlock as it keeps holding the RWLock.lock
spinlock while indirectly calling _threadrendezvous(). when
_threadrendezvous() switches to another thread in the same proc,
then that thread can hang at rlock()/wlock()/runlock() again
waiting for wunlock() to release the spinlock which will never
happen as lock() does not schedule threads.
wunlock() is changed to release the spinlock during rendezvous
wakeup of readers. note that this is a bit dangerous as more
readers might queue concurrently now which means that if
we cannot keep up with the wakeups, we might keep on waking
readers forever. that will be another patch for the future.
using "interrupt" ctl message directly doesnt work when the
process is doing libthread channel operations (threadrendezvous)
as it will just repeat a interrupted rendezvous(). threadint()
handles this for us.
threadint() is called to interrupt channel operation or a system call.
the kernel provides a new "interrupt" procctl message to interrupt a
process commited to or being in a blocking syscall, which is similar,
but not the same. the main difference is that "interrupt" condition
is not cleared before the process actually attempts to block. also
can be cleared with "nointerrupt" ctl message. see proc(3)
instead of ordering the source mount list, order the new destination
list which has the advantage that we do not need to wlock the source
namespace, so copying can be done in parallel and we do not need the
copy forward pointer in the Mount structure.
the Mhead back pointer in the Mount strcture was unused, removed.
there was a race between cunmount() and walk() on Mhead.from as Mhead.from was
unconditionally freed when we cunmount(), but findmount might have already
returned the Mhead in walk(). we have to ensure that Mhead.from is not freed
before the Mhead itself (now done in putmhead() once the reference count of the
Mhead drops to zero).
the Mhead struct contained two unused locks, removing.
no need to hold Pgrp.ns lock in closegrp() as nobody can get to it (refcount
droped to zero).
avoid cclose() and freemount() while holding Mhead.lock or Pgrp.ns locks as
it might block on a hung up fileserver.
remove the debug prints...
cleanup: use nil for pointers, remove redundant nil checks before putmhead().
we have to validaddr() and vmemchr() all argv[] elements a second
time when we copy to the new stack to deal with the fact that another
process can come in and modify the memory of the process doing the
exec. so the argv[] strings could have changed and increased in
length. we just make sure the data being copied will fit into the
new stack and error when we would overflow.
also make sure to free the ESEG in case the copy pass errors.
argv[] strings get copied to the new processes stack segment, which
has a maximum size of USTKSIZE, so limit the size of the strings to
that and check early for overflow.
this moves the name validation out of segattach() to syssegattach()
to make sure the segment name cannot be changed by the user while
segattach looks at it.
