dc: fix off by one in stack overflow check (thanks BurnZeZ)
BurnZeZ → Found a bug in dc(1)
BurnZeZ → Everything breaks when you fill the stack
BurnZeZ → You have stkptr which crap expects to point to an available member in Blk *stack[STKSZ];
BurnZeZ → stkend = &stack[STKSZ];
BurnZeZ → stkptr is allowed to equal stkend
BurnZeZ → So crap that expects stkptr to be pointing to an available Blk ends up dereferencing past the end of the array
BurnZeZ → term% echo `{seq 1 100} f | dc
BurnZeZ → dc 628283: suicide: sys: trap: fault read addr=0xffffe0000040a618 pc=0x204b1c
pc, pc64: look for "RSD PTR " in ACPI reserved memory region from e820 map
nobody passes us the "RSD PTR " address when doing multiboot/kexec
on UEFI systems. so we search for it manually in the ACPI reserved
area as indicated in the e820 memory map.
launch wadfs after detecting main wad, exposing GENMIDI and music lumps
under /mnt/wad. /bin/dmus can then use them directly, and wadfs doesn't
need to be started manually.
23hiro [Wed, 27 Jun 2018 17:20:28 +0000 (19:20 +0200)]
Persist 'k' command in mothra and add matching -k flag (thanks piroko)
"I sometimes find myself on either slow or data-capped network links where downloading images isn't ideal. Attached is a simple patch to mothra that changes the 'k' command to not only remove already-downloaded images from a page, but also toggle a state such that mothra won't attempt to download images on future visited sites until 'k' is toggled again. This also adds a '-k' flag to mothra which enables the flag at startup." --Jeremy O'Brien<neutral@fastmail.com> on 9fans
cinap_lenrek [Tue, 26 Jun 2018 17:30:52 +0000 (19:30 +0200)]
ndb/dns: fix encoding of srv record target
the target has to be encoded as a domain name (the individual
name components as separate labels followed by . (empty) label),
not as a literal string.
to disable compression, pass nil dictionary to pname().
qwx [Tue, 26 Jun 2018 08:35:23 +0000 (10:35 +0200)]
mus: fix note volume and channel selection; simplify
- fix overwriting channel 10 with channel 9
- fix using channel volume instead of last volume when setting note
(fixes d_doom and others)
- remove useless state
cinap_lenrek [Thu, 14 Jun 2018 18:48:21 +0000 (20:48 +0200)]
udp: fix udp checksum
we did not apply the special case to store 0xFFFF (-0)
in the checksum field when the checksum calculation
returned zero. we survived this for v4 as RFC768 states:
> If the computed checksum is zero, it is transmitted as
> all ones (the equivalent in one's complement arithmetic).
>
> An all zero transmitted checksum value means that the
> transmitter generated no checksum (for debuging or for
> higher level protocols that don't care).
for ipv6 however, the checksum is not optional and receivers
would drop packets with a zero checksum.
cinap_lenrek [Wed, 13 Jun 2018 22:07:45 +0000 (00:07 +0200)]
devip: don't send arp requests from null address
during dhcp, ipconfig assigns the null address :: which makes
ipforme() return Runi for any destination, which can trigger
arp resolution when we attempt to reply. so have v4local()
skip the null address and have sendarp() check the return
status of v4local(), avoing the spurious arp requests.
cinap_lenrek [Sun, 10 Jun 2018 17:47:21 +0000 (19:47 +0200)]
kernel: don't cap the minimum sleep time to TK2MS(1) for syssleep()
on HZ 100 systems like pc and pc64, the minium sleep time
was 10ms, which is quite high. the cap isnt really needed
as arch specific timerset() enforces its own limit, but on
a higher resolution.
background:
from Charles Forsyth:
I haven't really got an opinion on it. The 10ms interval was first used on
machines that were much slower.
I thought someone did set HZ to a bigger value, partly to support better
in-kernel timing. I haven't done it because I never had a need for it.
If I were doing (say) protocol implementation in user mode, I'd certainly
reconsider. Sleep itself forces at best ms granularity,
and for some applications that's too big.
initial mail from qwx raising the issue:
> Hello,
>
> I found out recently that sleep(2)'s resolution on 386 and 9front's amd64
> kernel is 10 ms rather than 1 ms. The reason is that on those kernels,
> HZ is set to 100 rather than say 1000. In syssleep, we get 1 tich every
> 10 ms.
>
> What is unclear is why.
>
> To paraphrase cinap_lenrek's answer to my question:
>
> In syssleep:
> if(ms < TK2MS(1))
> ms = TK2MS(1);
> tsleep(&up->sleep, return0, 0, ms);
>
> "TK2MS(1)" can be replaced with just "1", and the arch specific
> timerset() routine would do its own capping of the period if it's too
> small for the timer resolution, and make better decisions based on what
> the minimum timer period should be given the latency overhead of the
> given arch's interrupt handling and performance characteristics.
>
> Alternatively, HZ could be raised to 500 or 1000.
>
> It seems it's just trying to prevent excessive context switches and
> interrupts, but it seems somewhat arbitrary. A ton of syscalls can be
> done in 1 ms, and it's the lowest we can go without changing the unit.
>
>
> What do you think?
>
> Thanks in advance,
>
> qwx
cinap_lenrek [Sun, 3 Jun 2018 21:33:35 +0000 (23:33 +0200)]
kernel: stop the practice of passing DMDIR to devir() perm argument
devdir internally replicates the qid in ther perm stat field
already and the practice of explicitely passing just causing
confusion when done inconsistently.
projects / plan9front.git / log