there was a memory corruption bug caused by us enabling the
ps2mouseputc() handler *before* initializing packetsize.
once we enabled the handler, mouse interrupts could come
in and advance the packet buffer index (nb) beyond the
buffer boundaries.
as ps2mouseputc() only checked for ++nb == packetsize, once
nb was advanced beyond the packetsize, it would continue writing
beyond the buffer and corrupt memory with each mouse packet byte.
solution is to initialize packetsize *before* enabling the
handler, and also do a >= check in ps2mouseputc() in case the
packetsize gets changed to a smaller value at runtime.
we used to set RD flag in requests unconditionally, which
is fine by the standard but some dns server administrators
seem to use it as a denial of service indicator (for ther
non recursive authoritative nameservers) and ignore the
request.
so only set the RD flag when talking to local dns servers.
alexchandel got the kernel to crash with divide error
on qemu 2.1.2/macosx at this location. probably
caused by perfticks()/tsc being wrong or accounttime()
not having been called yet from timer interrupt yet for
some reason.
the syscall stubs (for amd64) currently have a unconditional
spill of the first (register) argument to the stack.
sysr1 (and _nsec) are exceptional in that they do not
take any arguments, so the stub is writing unconditionally
to ther first argument slot on the stack.
i could avoid emiting the spill in the syscall stubs for
sysr1 but that would also break truss which assumes fixed
instruction sequence from stub start to the syscall number.
i'm not going to complicate the syscall stubs just for
sysr1 (_nsec is not used in 9front), but just add a dummy
argument to sysr1 definition that can receive the bogus
argument spill.
devip can only handle Maskconv+1 conversations per
protocol depending on how many bits it uses in the
qid to encode the conversation number.
we check this when the protocol gets registered.
if we do not do this, the kernel will mysteriously
panic when the conversaion numbers collide which
took some time to debug.
we used to look for /^Plan 9$/ for the start of kernel
boot messages in /dev/kmesg. but the xen kernel prints
Plan 9 (.....) on boot. so just look for line starting
with /^Plan 9/ for now.
the numbers from /dev/sysstat overflow on 32bit, so have
to do subtraction modulo 2^32 as we calculate with 64bit
integers.
thanks mischief for reporting this.
WHAT WHERE THEY *THINKING*??!?!
unlike seek, the (new) nsec syscall (not used in 9front libc)
returns the time value in register (from nix), so do the same
for compatibility.
memfillcolor() used to write longs in host byte
order which is wrong. have to always use little
endian.
to simplify, moved little endian conversion into
memsetl() and memsets() avoiding code duplication.
file->parent can be nil when the file has been previously removed.
removefile() deals with this, so skip the permission check in
that case and let removefile() error out.
some of us run auth servers from home that are used by multiple
servers on the internet. when the home authserver becomes unreachable,
services on the outside servers stop working. so we thought about
specifing a secondary auth servers for backup when the primary
server is not reachable.
this changes authdial() to consult multiple auth= entries in
the authdom= or dom= tuples, trying each one in order until
dial() succeeds.
from segattach(2):
Va and len specify the position of the segment in the
process's address space. Va is rounded down to the nearest
page boundary and va+len is rounded up. The system does not
permit segments to overlap. If va is zero, the system will
choose a suitable address.
just rounding up len isnt enougth. we have to round up va+len
instead of just len so that the span [va, va+len) is covered
even if va is not page aligned.
kenjis example:
print("%p\n",ap); // 206cb0
ap = segattach(0, "shared", ap, 1024);
print("%p\n",ap); // 206000
term% cat /proc/612768/segment
Stack defff000 dffff000 1
Text R 1000 6000 1
Data 6000 7000 1
Bss 7000 7000 1
Shared 206000 207000 1
term%
note that 0x206cb0 + 0x400 > 0x20700.
RFC2104 defines HMAC for keys bigger than the 64 byte block
size as follows:
Applications that use keys longer than B (64) bytes will
first hash the key using H (the hash function) and then
use the resultant L byte string as the actual key to HMAC.
this is a work in progress implementation of the ayiya (anything
in anything) protocol as used by sixxs.net. hiro tested it and it
worked for him, but progress has stalled as sixxs.net rejected my
request for an account and ignored my emails since.