libpthread: remove a stale comment
the trick described by the comment has been removed in 2007.
("- Maintain a per-thread pointer to the last mutex acquired by...")
if: replace link state change queue with state transition
if_link_queue is now a normal bitmask rather than holding a queue.
It holds three bits to mirror the link state - UNKNOWN, DOWN and UP.
There are also some bits to indicate that the link state has been scheduled
for change and if it has been locked for changes (ie the interface being
destroyed).
The logic is simple - transitioning to DOWN will remove UNKNOWN and UP,
transitioning to UNKNOWN will remove UP (no driver should do this).
This means that even in the event of transitions happening faster than
the kernel can spit them out, the correct state of the link will be
preserved which is more important than the exact chain of events.
This also fixes an issue where the workqueue for the link state change
was incorrectly scheduled.
if_link_scheduled is now unused and will be removed in a future patch.
Fixes PR kern/60056.
libpthread: explain why pthread__allqueue has been kept
a bit history:
- libpthread_dbg has been removed from base in 2017.
- pkgsrc/devel/libpthread_dbg has been removed from pkgsrc in 2020.
the commit message of the removal was calling it "Legacy library out
of sync with NetBSD libpthread and without any users".
libpthread: fix pthread_main_np
the previous implementation was incorrect as pthread_t
of the main thread can be recycled via pthread__deadqueue.
with this changes, my test program [1] produces the same
result as macOS.
[1] https://github.com/yamt/garbage/tree/a24535e948dc62dde4c67366db97377e53d92e7b/c/pthread_main_np
an alternative fix would be to stop recycling the main thread
by simply leaking it. the leak is ok because, after all, it's
very rare for applications to continue after its main thread
exits. such applications don't even work as intended on some
of pthread implementations in the wild. for now, i'd go with
a more straightforward implementation though. ie. this commit.
cd9660: make sure that NM records are at least 5 bytes long.
avoids an integer underflow when this length has 5 subtracted from it
for a later path.
Reported by Adam Crosser, Praetorian
Make sure the start and end of the PT page ranges are aligned to the
size of what's addressable by a single PT page, thus ensuring we count
them up correctly.
In pmap_bootstrap1(), check to see if FIXEDVA entries in machine_bootmap[]
are covered by any existing page table range, and if not, allocate additional
page table ranges to cover them.
This does not impact the one current user of FIXEDVA -- hp300 -- which
uses it to map the last page of RAM VA==PA. In the hp300 case, this
was already covered by the PTs that map the alternate SYSMAP_VA that
the hp300 uses (precisely because it needs the last VA==PA mapping).
This will eventually be used to map the I/O region VA==PA for mac68k.
Normally, we might otherwies use a TT register for that, but mac68k
runs on 68020s, so we cannot.
Two issues:
- Always include vmparams.h via <machine/vmparams.h>, because redirection
logic elsewhere relies on this.
- But akshually, isn't not even needed here because the code that would
use it is #if 0'd out anyway.
So, collect the garbage and ramble on.
Pull up following revision(s) (requested by martin in ticket #275):
share/mk/bsd.own.mk: 1.1481 via patch
PR 58762: disable MKCOMPAT for earm*.
If someone is interested in re-adding support for oabi compat library
builds, they can figure out the missing bits. But for now, stop producing
bogus compat32/debug32 sets on all evbarm builds.
Pull up following revision(s) (requested by martin in ticket #274):
usr.bin/cksum/cksum.c: 1.53
PR 60154: do not print arbitrary control characters when printing
file names while checking hashes with the -c option.
Remove the upper bound on nkmempages for virt68k, else the kmem arena
gets easily starved on VMs with large memory configs (which is sort of
the whole point of virt68k).
